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.