From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11051 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: syscall table discrepancies Date: Thu, 16 Feb 2017 21:00:44 -0500 Message-ID: <20170217020044.GN1520@brightrain.aerifal.cx> References: <20170217015147.GA7188@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1487296859 8855 195.159.176.226 (17 Feb 2017 02:00:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 17 Feb 2017 02:00:59 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-11066-gllmg-musl=m.gmane.org@lists.openwall.com Fri Feb 17 03:00:55 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1ceXqw-0001xu-30 for gllmg-musl@m.gmane.org; Fri, 17 Feb 2017 03:00:54 +0100 Original-Received: (qmail 20123 invoked by uid 550); 17 Feb 2017 02:00:58 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 20105 invoked from network); 17 Feb 2017 02:00:57 -0000 Content-Disposition: inline In-Reply-To: <20170217015147.GA7188@brightrain.aerifal.cx> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:11051 Archived-At: 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