[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170217020044.GN1520@brightrain.aerifal.cx>
Date: Thu, 16 Feb 2017 21:00:44 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
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
fixed.
> -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:
https://sourceware.org/ml/libc-alpha/2017-01/msg00074.html
> 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?
Rich
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.
