This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH-for-2.21-and-2.22] s390-64: remove socketcall syscalls


On 2015-12-31 18:21, Joseph Myers wrote:
> On Fri, 25 Dec 2015, Aurelien Jarno wrote:
> 
> > From: Stefan Liebler <stli@linux.vnet.ibm.com>
> > 
> > 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
understood.

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.

Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]