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 Friday 25 December 2015 03:21:38 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.
> 
> ChangeLog:
> 
> 	* sysdeps/unix/sysv/linux/s390/s390-64/syscalls.list:
> 	Remove socketcall syscalls.
> 
> (partially cherry picked from commit 016495b818cb61df7d0d10e6db54074271b3e3a5)
> ---
>  ChangeLog                                          |  5 +++++
>  sysdeps/unix/sysv/linux/s390/s390-64/syscalls.list | 19 -------------------
>  2 files changed, 5 insertions(+), 19 deletions(-)
> 
> This is a partial backport of commit 016495b8 which is already on master
> and is needed when building glibc against 4.3+ kernel headers. Otherwise
> we end up with wrong code, like this one for socket:

Hi Stefan,

Can you explain what exactly went wrong? I see that the same change that
was done in the kernel headers also made it into the m68k and x86
architectures:

Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Sun Sep 6 11:59:27 2015 +0200

    m68k: Wire up direct socket calls
    
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Acked-by: Greg Ungerer <gerg@uclinux.org>
commit 9dea5dc921b5f4045a18c63eb92e84dc274d17eb
Author: Andy Lutomirski <luto@kernel.org>
Date:   Tue Jul 14 15:24:24 2015 -0700

    x86/entry/syscalls: Wire up 32-bit direct socket calls


Do those have the same problem? Is there a way to avoid the problem for
other architectures that want to add the separate calls later?

	Arnd


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