This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH-for-2.21-and-2.22] s390-64: remove socketcall syscalls
- From: Aurelien Jarno <aurelien at aurel32 dot net>
- To: Joseph Myers <joseph at codesourcery dot com>, libc-alpha at sourceware dot org, Stefan Liebler <stli at linux dot vnet dot ibm dot com>
- Date: Thu, 31 Dec 2015 23:28:45 +0100
- Subject: Re: [PATCH-for-2.21-and-2.22] s390-64: remove socketcall syscalls
- Authentication-results: sourceware.org; auth=none
- References: <1451010098-22120-1-git-send-email-aurelien at aurel32 dot net> <alpine dot DEB dot 2 dot 10 dot 1512311816490 dot 15940 at digraph dot polyomino dot org dot uk> <20151231211353 dot GH360 at aurel32 dot net>
On 2015-12-31 22:13, Aurelien Jarno wrote:
> On 2015-12-31 18:21, Joseph Myers wrote:
> > On Fri, 25 Dec 2015, Aurelien Jarno wrote:
> > > From: Stefan Liebler <firstname.lastname@example.org>
> > >
> > > Remove socketcalls in syscalls.list for s390-64. They were never used
> > > on s390x and produce wrong code when glibc is built against 4.3 kernel
> > > headers.
> > Could you explain why they produce wrong code?
> I personally haven't checked. I have seen that compiling glibc against
> 4.3 kernel headers produced this wrong code. I then looked on master and
> then realized these syscalls have been removed from syscalls.list. I
> haven't really investigating more given I though the problem was
> All that said we don't want these syscalls to be used as soon as we use
> recent enough kernel headers as the resulting libc might be then used on
> an older kernel.
> > Long term, once we can assume a kernel with direct socket syscalls on all
> > architectures, we should get rid of socketcall support. And the preferred
> > form of getting rid of it isn't to have lots of C files calling syscall
> > macros. It's to use syscalls.list entries where possible, with C files
> > only if needed because e.g. a function doesn't correspond directly to a
> > syscall (Adhemerval's cancellation changes would add "syscall is a
> > cancellation point" to the cases needing C files; I'm unconvinced that
> > reducing the number of cases that can use syscalls.list is a good idea).
> > And those syscalls.list entries would where possible be those in
> > sysdeps/unix/syscalls.list (appropriately adjusted to be in sync with the
> > current Linux-specific entries as needed).
> > So, if there are cases where listing such a syscall in syscalls.list
> > produces wrong code, we need to understand those cases properly so we can
> > allow for them in the future when eliminating socketcall support and using
> > syscalls.list entries in more cases, architecture-independent.
> Ok, I'll try to investigate in the next days.
I have found some times to investigate. It seems there is no issue, my
bad. I just discovered that on s390x, syscalls numbers above 256 are
actually a a call to syscall 0 with the syscall number passed in
register %r1. My version of strace was not aware of the new syscalls
and presented them as syscall setup(). Sorry for the false alert.
So it seems all is fine, but we still need the patch to use the
socketcall interface until we can assume the direct socket syscalls are
always available. I'll repost the patch on the libc-stable interface
with the comment fixed, as I have been told in the meantimes it's a
better list for discussing about already released versions.
Aurelien Jarno GPG: 4096R/1DDD8C9B