This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/21029] glibc-2.23 (and later) fails to compile with -fno-omit-frame-pointer on i386
- From: "adhemerval.zanella at linaro dot org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Sat, 07 Jan 2017 13:35:35 +0000
- Subject: [Bug libc/21029] glibc-2.23 (and later) fails to compile with -fno-omit-frame-pointer on i386
- Auto-submitted: auto-generated
- References: <bug-21029-131@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=21029
Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Last reconfirmed| |2017-01-07
Resolution|DUPLICATE |---
Ever confirmed|0 |1
--- Comment #6 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to Jan Ziak (http://atom-symbol.net) from comment #3)
> (In reply to Adhemerval Zanella from comment #1)
> > AFAIK it is not an issue because 'ebp' is this context is used on kernel ABI
> > to pass the 6th argument (the file sysdeps/unix/sysv/linux/i386/sysdep.h
> > contains a comment about the linux convention for i686).
>
> It's an issue as long as it is fixable in glibc. The fact is, it *is*
> fixable in glibc.
>
> It's an issue as long as it is fixable in gcc. The fact is, it *is* fixable
> in gcc.
>
> It's an issue as long as it is fixable in the Linux kernel. The fact is, it
> *is* fixable in Linux kernel.
>
> It's an issue as long as it is fixable on my machine alone. The fact is, it
> *is* fixable on my machine alone.
>
> The question is: which software component is the easiest to change and will
> have the most impact on the world.
It was a bad wording from my part, my idea is since we already have a solution
for correct 6-argument passing for compiler that might use the 6th argument
passing it should not be an issue on GLIBC.
However I wrongly assumed this could not be accomplished on this code, which it
wrong.
>
> > Unless there is a compiler option to make easier to create syscall macros
> > (so compiler can restore ebp somehow), you will need to explict disable
> > -fno-omit-frame-pointer on these files.
> >
> > Another option would to code this syscalls in asm, but I will advise against
> > since to make i386 to use the generic code is exactly to avoid the
> > proliferation of such implementations.
>
> The best solution is the update the definition of INTERNAL_SYSCALL with
> something like this:
>
> LOADREGS_##nr(args)
> asm volatile (
> PUSHREGS_ASM_##nr(args)
> "call *%%gs:%P2"
> POPREGS_ASM_##nr
> : "=a" (resultvar)
>
> #define PUSHREGS_ASM_5(args...) "" // empty
> #define PUSHREGS_ASM_6(args...) "push %%ebp; mov arg6, %%ebp;"
>
> #define POPREGS_ASM_5 "" // empty
> #define POPREGS_ASM_6 "pop %%ebp"
Your solution is wrong and do not address the issue in question. This snippet
is not related to C macros for syscall macros, but rather to auto-generated
syscalls which is code and implemented directly in assembly.
Six argument syscalls from C macros were fixed by a9fe4c5aa8e53ee3 and then
optimized on 98ad631cd0a77. The optimization takes in consideration than if
you are using GCC 5, the compiler an properly spill %ebx when needed, we can
inline syscalls with 6 arguments.
The problem is it does not take in consideration that for fomit-frame-pointer
compiler option on i686 we can not use this optimization (as for PROF which was
corrected by 95b097779a6).
I could get a working build with the scratch patch:
-----
diff --git a/sysdeps/unix/sysv/linux/i386/Makefile
b/sysdeps/unix/sysv/linux/i386/Makefile
index 9609752..cd5bb43 100644
--- a/sysdeps/unix/sysv/linux/i386/Makefile
+++ b/sysdeps/unix/sysv/linux/i386/Makefile
@@ -3,7 +3,7 @@ default-abi := 32
# %ebp is used to pass the 6th argument to system calls, so these
# system calls are incompatible with a frame pointer.
-uses-6-syscall-arguments = -fomit-frame-pointer
+uses-6-syscall-arguments = -DNO_OPTIMIZE_FOR_GCC_5
ifeq ($(subdir),misc)
sysdep_routines += ioperm iopl vm86
@@ -24,6 +24,7 @@ CFLAGS-semtimedop.os += $(uses-6-syscall-arguments)
endif
ifeq ($(subdir),elf)
+sysdep-dl-routines += libc-do-syscall
sysdep-others += lddlibc4
install-bin += lddlibc4
endif
@@ -61,6 +62,8 @@ ifeq ($(subdir),nptl)
# pull in __syscall_error routine
libpthread-routines += sysdep
libpthread-shared-only-routines += sysdep
+CFLAGS-pthread_cond_wait.o += $(uses-6-syscall-arguments)
+CFLAGS-pthread_cond_wait.os += $(uses-6-syscall-arguments)
CFLAGS-pthread_rwlock_timedrdlock.o += $(uses-6-syscall-arguments)
CFLAGS-pthread_rwlock_timedrdlock.os += $(uses-6-syscall-arguments)
CFLAGS-pthread_rwlock_timedwrlock.o += $(uses-6-syscall-arguments)
diff --git a/sysdeps/unix/sysv/linux/i386/libc-do-syscall.S
b/sysdeps/unix/sysv/linux/i386/libc-do-syscall.S
index f706c6d..ef9e513 100644
--- a/sysdeps/unix/sysv/linux/i386/libc-do-syscall.S
+++ b/sysdeps/unix/sysv/linux/i386/libc-do-syscall.S
@@ -18,7 +18,7 @@
#include <sysdep.h>
-#ifndef OPTIMIZE_FOR_GCC_5
+//#ifndef OPTIMIZE_FOR_GCC_5
/* %eax, %ecx, %edx and %esi contain the values expected by the kernel.
%edi points to a structure with the values of %ebx, %edi and %ebp. */
@@ -50,4 +50,4 @@ ENTRY (__libc_do_syscall)
cfi_restore (ebx)
ret
END (__libc_do_syscall)
-#endif
+//#endif
diff --git a/sysdeps/unix/sysv/linux/i386/sysdep.h
b/sysdeps/unix/sysv/linux/i386/sysdep.h
index baf4642..e35cc02 100644
--- a/sysdeps/unix/sysv/linux/i386/sysdep.h
+++ b/sysdeps/unix/sysv/linux/i386/sysdep.h
@@ -46,7 +46,7 @@
to compile glibc. Disable GCC 5 optimization when compiling for
profiling since asm ("ebp") can't be used to put the 6th argument
in %ebp for syscall. */
-#if __GNUC_PREREQ (5,0) && !defined PROF
+#if __GNUC_PREREQ (5,0) && !defined PROF && !defined NO_OPTIMIZE_FOR_GCC_5
# define OPTIMIZE_FOR_GCC_5
#endif
-----
It is not optimal since we want NO_OPTIMIZE_FOR_GCC_5 only when
omit-frame-pointer is used and it will require most likely an configure check
to do so. I will think in a better solution.
--
You are receiving this mail because:
You are on the CC list for the bug.