[Bug c/45286] kact.sa_restorer = &restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64

[Bug c/45286] kact.sa_restorer = &restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64

[zorry at gentoo dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286

--- Comment #21 from Magnus Granberg <zorry at gentoo dot org> ---
Do this happen on gcc 6.0 with --enable-default-pie and trunk glibc?

[Bug c/45286] kact.sa_restorer = &restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286

--- Comment #22 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Magnus Granberg from comment #21)
> Do this happen on gcc 6.0 with --enable-default-pie and trunk glibc

I built glibc master using gcc 6.0 with --enable-default-pie and
there are no problems on x86-64.

[Bug c/45286] New: kact.sa_restorer = &restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64

[zorry at ume dot nu]

http://bugs.gentoo.org/show_bug.cgi?id=283470
kact.sa_restorer = &restore_rt; get miss compile with -fPIE
with -fPIC the code get
48 8d 05 2e ff ff ff    lea    -0xd2(%rip),%rax   # 10 <__restore_rt>
and with -fPIE it get
48 8b 05 2e ff ff ff    mov    -0xd2(%rip),%rax   # 10 <__restore_rt>
Later on when we try to use the function in some code it segfault.
so it would seem gcc is miscompiling the x86_64 sigaction.c code. 
specifically, this bit of sysdeps/unix/sysv/linux/x86_64/sigaction.c


-- 
           Summary: kact.sa_restorer = &restore_rt; in sigaction.c glibc get
                    miss compile with -fPIE on x86_64
           Product: gcc
           Version: 4.4.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: zorry at ume dot nu
GCC target triplet: x86_64


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286

[Bug c/45286] kact.sa_restorer = &restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64

[zorry at ume dot nu]

------- Comment #1 from zorry at ume dot nu  2010-08-15 01:02 -------
Created an attachment (id=21477)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21477&action=view)
compile with -fPIE

This file is compile with -fPIE


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286

[Bug c/45286] kact.sa_restorer = &restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64

[zorry at ume dot nu]

------- Comment #2 from zorry at ume dot nu  2010-08-15 01:04 -------
Created an attachment (id=21478)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21478&action=view)
compile with -fPIC -DSHARED

file compiled with -fPIC -DSHARED


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286

[Bug c/45286] kact.sa_restorer = &restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64

[hjl dot tools at gmail dot com]

------- Comment #3 from hjl dot tools at gmail dot com  2010-08-15 02:25 -------
(In reply to comment #0)
> http://bugs.gentoo.org/show_bug.cgi?id=283470
> kact.sa_restorer = &restore_rt; get miss compile with -fPIE
> with -fPIC the code get
> 48 8d 05 2e ff ff ff    lea    -0xd2(%rip),%rax   # 10 <__restore_rt>
> and with -fPIE it get
> 48 8b 05 2e ff ff ff    mov    -0xd2(%rip),%rax   # 10 <__restore_rt>

It doesn't necessarily mean wrong.

> Later on when we try to use the function in some code it segfault.
> so it would seem gcc is miscompiling the x86_64 sigaction.c code. 
> specifically, this bit of sysdeps/unix/sysv/linux/x86_64/sigaction.c

Please extract a small static testcase which shows the
miscompiled sigaction.c when linking with a libc.a. I
want to know how sigaction.c is compiled.


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286

[Bug c/45286] kact.sa_restorer = &restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64

[vapier at gentoo dot org]

------- Comment #4 from vapier at gentoo dot org  2010-08-15 04:41 -------
what are you looking for ?  miscompiled objects ?  linking sigaction.c with a
libc.a doesnt make sense as the libc.a already contains sigaction.o.  or you
want an example app linked against a miscompiled libc.a ?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286

[Bug c/45286] kact.sa_restorer = &restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64

[hjl dot tools at gmail dot com]

------- Comment #5 from hjl dot tools at gmail dot com  2010-08-15 05:40 -------
Please help me reproduce it with a run-time testcase. I can build
libc.a.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286

[Bug c/45286] kact.sa_restorer = &restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64

[vapier at gentoo dot org]

------- Comment #6 from vapier at gentoo dot org  2010-08-15 05:49 -------
Created an attachment (id=21479)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21479&action=view)
signaler.c

register a signal handler that goes though __libc_sigaction(), then trigger
that signal and attempt to return.  since glibc set the sa_restorer field by
reading the data at the address of __rt_sigaction instead of using the address
itself, the kernel sets the return address to an invalid address.

here is a semi-overly-complicated example:
  gcc -o signaler signaler.c -static
  ./signaler

set a break point at *sigvtalarm and look at the return address:
  (gdb) x/1g $rsp
  0x7fffffffd1f8: 0x0f0000000fc0c748

that's because gcc generated a mov insn which loaded the 64bits at the address
of __restore_rt instead of storing the address of __restore_rt itself:

0000000000000010 <__restore_rt>:
  10:   48 c7 c0 0f 00 00 00    mov    $0xf,%rax
  17:   0f 05                   syscall 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286

[Bug c/45286] kact.sa_restorer = &restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64

[hjl dot tools at gmail dot com]

------- Comment #7 from hjl dot tools at gmail dot com  2010-08-15 20:36 -------
It works for me:

(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /export/home/hjl/bugs/gcc/pr45286/foo 

Breakpoint 1, sigvtalarm (foo=0) at foo.c:25
25      {
(gdb) x/1g $rsp
0x7fffffffde38: 0x0000000000401060
(gdb) disass 0x0000000000401060
Dump of assembler code for function __restore_rt:
   0x0000000000401060 <+0>:     mov    $0xf,%rax
   0x0000000000401067 <+7>:     syscall 
   0x0000000000401069 <+9>:     nopl   0x0(%rax)
End of assembler dump.
(gdb) 

You have to show me how I can reproduce miscompiled
sigaction.c.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286

[Bug c/45286] kact.sa_restorer = &restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64

[vapier at gentoo dot org]

------- Comment #8 from vapier at gentoo dot org  2010-08-15 20:40 -------
yes, we did.  take the .i files we already posted and compile them with the
quoted pic/pie flags and look at the disassembled code.

the hardened gentoo variant builds all of glibc with pic/pie support (including
static libraries) which is why building a stock glibc with stock gcc wont hit
the problem.

i dont see how the disassembled code using mov to load up data can work.  is it
attempting to read a PLT entry or something ?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286

[Bug c/45286] kact.sa_restorer = &restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64

[hjl dot tools at gmail dot com]

------- Comment #9 from hjl dot tools at gmail dot com  2010-08-15 20:45 -------
You have to show me exact CFLAGS used to compile sigaction.c.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286

[Bug c/45286] kact.sa_restorer = &restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64

[vapier at gentoo dot org]

------- Comment #10 from vapier at gentoo dot org  2010-08-15 21:01 -------
from the glibc-2.11.2/signal/ subdir:

$ gcc -Wall -Winline -Wwrite-strings -Wstrict-prototypes -std=gnu99 -O2
-fgnu89-inline -fmerge-all-constants -fno-strict-aliasing -fno-unwind-tables -g
-pipe '-DWRAPPER_INCLUDE=<nptl/sigaction.c>' -I../include
-I/var/tmp/portage/sys-libs/glibc-2.11.2/work/build-amd64-x86_64-pc-linux-gnu-nptl/signal
-I/var/tmp/portage/sys-libs/glibc-2.11.2/work/build-amd64-x86_64-pc-linux-gnu-nptl
-I../sysdeps/x86_64/elf -I../nptl/sysdeps/unix/sysv/linux/x86_64
-I../sysdeps/unix/sysv/linux/x86_64 -I../sysdeps/unix/sysv/linux/wordsize-64
-I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread
-I../sysdeps/pthread -I../ports/sysdeps/unix/sysv/linux
-I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common
-I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../nptl/sysdeps/unix/sysv
-I../ports/sysdeps/unix/sysv -I../sysdeps/unix/sysv -I../sysdeps/unix/x86_64
-I../nptl/sysdeps/unix -I../ports/sysdeps/unix -I../sysdeps/unix
-I../sysdeps/posix -I../sysdeps/x86_64/fpu -I../nptl/sysdeps/x86_64
-I../sysdeps/x86_64 -I../sysdeps/wordsize-64 -I../sysdeps/ieee754/ldbl-96
-I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754
-I../sysdeps/generic/elf -I../sysdeps/generic -I../nptl -I../ports -I..
-I../libio -I. -nostdinc -isystem
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/include -isystem
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/include-fixed -isystem /usr/include
-D_LIBC_REENTRANT -include ../include/libc-symbols.h -U_FORTIFY_SOURCE -DPIC
../sysdeps/unix/sysv/linux/x86_64/sigaction.c -c -o sigaction.o -fPIC -fPIE

$ objdump -d -r sigaction.o | grep rax.*restore
  db:   48 8b 05 2e ff ff ff    mov    -0xd2(%rip),%rax   # 10 <__restore_rt>

emphasis is that it is PIC+PIE+NOSHARED


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286

[Bug c/45286] kact.sa_restorer = &restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64

[hjl dot tools at gmail dot com]

------- Comment #11 from hjl dot tools at gmail dot com  2010-08-15 21:15 -------
It works for me with -fPIC -fPIE using gcc 4.4.4 on
Fedora 13. I got

        movq    __restore_rt@GOTPCREL(%rip), %rax
        movq    %rax, 56(%rsp)

in assembly output. It is correct. Please make sure that
you use the current Linux binutils.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286

[Bug c/45286] kact.sa_restorer = &restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64

[zorry at ume dot nu]

------- Comment #12 from zorry at ume dot nu  2010-08-15 21:31 -------
(In reply to comment #11)
> It works for me with -fPIC -fPIE using gcc 4.4.4 on
> Fedora 13. I got
> 
>         movq    __restore_rt@GOTPCREL(%rip), %rax
>         movq    %rax, 56(%rsp)
> 
> in assembly output. It is correct. Please make sure that
> you use the current Linux binutils.
> 
what do you get only with -fPIE?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286

[Bug c/45286] kact.sa_restorer = &restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64

[hjl dot tools at gmail dot com]

------- Comment #13 from hjl dot tools at gmail dot com  2010-08-15 21:36 -------
(In reply to comment #12)
> (In reply to comment #11)
> > It works for me with -fPIC -fPIE using gcc 4.4.4 on
> > Fedora 13. I got
> > 
> >         movq    __restore_rt@GOTPCREL(%rip), %rax
> >         movq    %rax, 56(%rsp)
> > 
> > in assembly output. It is correct. Please make sure that
> > you use the current Linux binutils.
> > 
> what do you get only with -fPIE?

The same. Please try the current Linux binutils from:

http://www.kernel.org/pub/linux/devel/binutils/

It could be a linker bug.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286

[Bug c/45286] kact.sa_restorer = &restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64

[vapier at gentoo dot org]

------- Comment #14 from vapier at gentoo dot org  2010-08-15 21:59 -------
we are using current GNU binutils (2.20.1).  we dont use Linux binutils anymore
in Gentoo by default due to the instability and random patches that never get
mainlined into the GNU binutils.  however, even with binutils-2.20.51.0.11, i
get the same behavior:
  f8:   48 8b 05 11 ff ff ff    mov    -0xef(%rip),%rax   # 10 <__restore_rt>

while the initial report is gcc-4.3.4, same behavior can be observed with
gcc-4.4.4.  seems general users (like me) cannot update the Known-to-fail
field.

how can it be a linker bug if the compiled .o seems to be incorrect ?  i dont
think lazy linking changes the actual code generated ?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286

[Bug c/45286] kact.sa_restorer = &restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64

[rguenth at gcc dot gnu dot org]

------- Comment #15 from rguenth at gcc dot gnu dot org  2010-08-15 22:11 -------
(In reply to comment #14)
> we are using current GNU binutils (2.20.1).  we dont use Linux binutils anymore
> in Gentoo by default due to the instability and random patches that never get
> mainlined into the GNU binutils.

That's ok - I think nobody uses Linux binutils anymore.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286

[Bug c/45286] kact.sa_restorer = &restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64

[jakub at gcc dot gnu dot org]

------- Comment #16 from jakub at gcc dot gnu dot org  2010-08-16 11:16 -------
Re: #c12, the difference is because the source code is different.
In the first preprocessed source, restore_rt isn't hidden, in the latter it is.
So, in the first case (-fPIE) gcc can't assume __restore_rt is defined in the
same shared library or binary, in the latter case it can.
Shorter testcase is:
extern void foo (void) asm ("baz")
#ifdef HIDDEN
__attribute__((visibility ("hidden")))
#endif
;
void *bar (void)
{
  return &foo;
}
asm (".text; .type baz, @function; baz: nop; .previous");

-fpie vs. -fpic -DHIDDEN, the only difference is again:
-       movq    baz@GOTPCREL(%rip), %rax
+       leaq    baz(%rip), %rax

So, if there is any bug, it is either on the assembler/ld side, or on the glibc
side or user side, compiling glibc in a way it was never meant to be compiled.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286

[Bug c/45286] kact.sa_restorer = &restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64

[vapier at gentoo dot org]

------- Comment #17 from vapier at gentoo dot org  2010-08-18 03:23 -------
thanks for the shorter test case.  could you explain why a 64bit load is used
though ?  if you're looking for the address of something, and you're not going
through a pointer to that location, why isnt it a normal lea with a relocation
?

your short test case though doesnt show exactly the same as ours ... we arent
going through the GOT or have a relocation on the load ...

as for compiling glibc as it wasnt meant to be, that's pretty vague.  i think
the only way to get a glibc the way it is _meant_ to be compiled is by getting
a binary package from drepper himself.  and even then, who knows.  for a
project that doesnt support cross-compiling, doesnt support static linking,
doesnt support a good number of architectures, it's no wonder eglibc exists.  i
hate to point out that Gentoo was doing SSP/PIE light years before Redhat and
glibc/gcc, and that was "unsupported" for a long time too.  now it's a stock
part of glibc ...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286

[Bug c/45286] kact.sa_restorer = &restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64

[hjl dot tools at gmail dot com]

------- Comment #18 from hjl dot tools at gmail dot com  2010-08-18 03:29 -------
If you believe it is a gcc bug, please provide a small run-time
testcase which can be linked with any /usr/lib64/libc.a compiled
from glibc 2.12. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286

[Bug c/45286] kact.sa_restorer = &restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64

[vapier at gentoo dot org]

------- Comment #19 from vapier at gentoo dot org  2010-08-18 03:39 -------
as we stated, you wont hit the bug with vanilla gcc + vanilla glibc.  we also
arent absolutely stating "this is a gcc bug".  our dissection of the problem
lead us from cryptsetup to glibc to what seems like a gcc miscompilation of
glibc.  but we arent the gcc experts, so we look to you guys for guidance to
locate the real source of the bug.

i'll try and figure out some steps to reproduce the issue starting with
glibc/gcc tarballs.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286

[Bug c/45286] kact.sa_restorer = &restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64

[hjl dot tools at gmail dot com]

------- Comment #20 from hjl dot tools at gmail dot com  2010-08-18 03:59 -------
(In reply to comment #19)
> as we stated, you wont hit the bug with vanilla gcc + vanilla glibc.  we also
> arent absolutely stating "this is a gcc bug".  our dissection of the problem
> lead us from cryptsetup to glibc to what seems like a gcc miscompilation of
> glibc.  but we arent the gcc experts, so we look to you guys for guidance to
> locate the real source of the bug.
> 

You can link your sigaction.o with another libc.a to show the problem IF
the problem is in your sigaction.o. If it is the case, please show me
your sigaction.i and CFLAGS used to compile it.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286