Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 16 Feb 2017 21:00:44 -0500
From: Rich Felker <>
Subject: Re: syscall table discrepancies

On Thu, Feb 16, 2017 at 08:51:47PM -0500, Rich Felker wrote:
> Szabolcs Nagy worked out diffs of musl's idea of the syscalls for each
> arch vs the kernel's which I'm pasting below; I'll follow up with
> comments as a reply.
> aarch64
> -o__NR_fstatat 79
> +o__NR_newfstatat 79

This is just a matter of naming and does not affect correct
compilation of musl (musl remaps this anyway in
src/internal/syscall.h) but it can affect third-party code that
expects specific names; compiler-rt hit this. I think it should be

> -o__NR_or1k_atomic 244

Obvious foreign-arch cruft that should be removed.

> arm
> +o__NR_arm_fadvise64_64 270
> +o__NR_arm_sync_file_range 341
> -o__NR_fadvise64_64 270

Also a naming matter and one I'd probably rather not change, though
I'm not sure. It looks like powerpc has the same nonstandard arg order
for fadvise but doesn't use a different name, so it's not really
helpful for arm to use a different name here.

Not sure about sync_file_range; it might suggest we have a bug.

> i386
> -o__NR_madvise1 219

I think this is cruft that was removed...?

> microblaze
> -o__NR_fadvise 250
> +o__NR_fadvise64 250
> -o__NR_fstatat 300
> +o__NR_fstatat64 300
> -o__NR_pread 180
> +o__NR_pread64 180
> -o__NR_pwrite 181
> +o__NR_pwrite64 181

These should probably be renamed to match the kernel;
src/internal/syscall.h renames them back anyway, but third-party code
may expect the kernel's names.

> mips
> +o__NR__newselect 4142
> -o__NR_fadvise 4254
> +o__NR_fadvise64 4254
> -o__NR_fstatat 4293
> +o__NR_fstatat64 4293
> -o__NR_pread 4200
> +o__NR_pread64 4200
> -o__NR_pwrite 4201
> +o__NR_pwrite64 4201
> -o__NR_select 4142

Likewise here.

> mipsn32
> -o__NR_fstatat 6256
> +o__NR_newfstatat 6256

Purely a naming issue, but should be changed I think.

> or1k
> -o__NR__llseek 62
> +o__NR_llseek 62

This looks like a bug that probably has lseek broken on or1k with
files larger than 2GB... I think the #else case in lseek.c should
probably be tweaked to produce a compile-time error if syscall_arg_t
is 32-bit. That would also catch musl's equivalent of this n32 bug
which remains unfixed:

> powerpc
> -o__NR_getresgid32 170
> -o__NR_getresuid32 165
> -o__NR_setresgid32 169
> -o__NR_setresuid32 164

These can probably be safely removed; I suspect they were cruft from
before the general renaming in src/internal/syscall.h was in place.

> -o__NR_timerfd 306

Also a leftover/legacy name, I presume?


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.