This is the mail archive of the glibc-bugs@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]

[Bug libc/21029] glibc-2.23 (and later) fails to compile with -fno-omit-frame-pointer on i386


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.

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