[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250301162242.GR1827@brightrain.aerifal.cx>
Date: Sat, 1 Mar 2025 11:22:42 -0500
From: Rich Felker <dalias@...c.org>
To: Dmitry Vyukov <dvyukov@...gle.com>, musl@...ts.openwall.com
Subject: Re: Support for -static-pie relocations
On Sat, Mar 01, 2025 at 05:10:39PM +0100, Szabolcs Nagy wrote:
> * Dmitry Vyukov <dvyukov@...gle.com> [2025-03-01 16:08:52 +0100]:
>
> > Hello,
> >
> > This simple program crashes when compiled with -static-pie:
> >
> > #include <stdio.h>
> > int main() { fprintf(stderr, "Hello\n"); }
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x0000000000001170 in ?? ()
> > (gdb) bt
> > #0 0x0000000000001170 in ?? ()
> > #1 0x00007ffff7ffb3b8 in libc_start_init () at src/env/__libc_start_main.c:64
> > #2 0x00007ffff7ffb3e8 in libc_start_main_stage2 (main=0x7ffff7ffb180
> > <main>, argc=1, argv=0x7fffffffdc98)
> > at src/env/__libc_start_main.c:92
> > #3 0x00007ffff7ffb0b1 in _start ()
> >
> > (gdb) up
> > #1 0x00007ffff7ffb3b8 in libc_start_init () at src/env/__libc_start_main.c:64
> > 64 (*(void (**)(void))a)();
> >
> > (gdb) disass
> > Dump of assembler code for function libc_start_init:
> > 0x00007ffff7ffb39b <+0>: push %rbp
> > 0x00007ffff7ffb39c <+1>: push %rbx
> > 0x00007ffff7ffb39d <+2>: sub $0x8,%rsp
> > 0x00007ffff7ffb3a1 <+6>: call 0x7ffff7ffb000 <_init>
> > 0x00007ffff7ffb3a6 <+11>: lea 0x2a9b(%rip),%rbx # 0x7ffff7ffde48
> > 0x00007ffff7ffb3ad <+18>: lea 0x2a9c(%rip),%rbp # 0x7ffff7ffde50
> > 0x00007ffff7ffb3b4 <+25>: jmp 0x7ffff7ffb3bc <libc_start_init+33>
> > 0x00007ffff7ffb3b6 <+27>: call *(%rbx)
> > => 0x00007ffff7ffb3b8 <+29>: add $0x8,%rbx
> > 0x00007ffff7ffb3bc <+33>: cmp %rbp,%rbx
> > 0x00007ffff7ffb3bf <+36>: jb 0x7ffff7ffb3b6 <libc_start_init+27>
> > 0x00007ffff7ffb3c1 <+38>: add $0x8,%rsp
> > 0x00007ffff7ffb3c5 <+42>: pop %rbx
> > 0x00007ffff7ffb3c6 <+43>: pop %rbp
> > 0x00007ffff7ffb3c7 <+44>: ret
> > End of assembler dump.
> >
> > (gdb) p /x $rbx
> > $1 = 0x7ffff7ffde48
> > (gdb) p /x *(void**)$rbx
> > $2 = 0x1170
> >
> > This 0x1170 is probably a ctor pointer offset that wasn't relocated.
> >
> > A fix would probably be calling _dl_relocate_object() somewhere on the
> > __libc_start_main() path.
> >
> > Is there a reason this is not supported? Or merely not implemented yet?
> > Can't find an issue tracker nor searchable archives for previous
> > discussions on this...
> >
> > Thanks in advance
>
> i think this is a disagreement about what dynrelocs may appear in
> static pie between musl and binutils.
>
> it is a linker bug if static pie has non-relative relocs.
> in this case likely there is a symbolic reloc for the init array
> entry even though we know the symbol value at link time.
> check the readelf output. (alternative theory: the relocs are
> missing: bfd ld had bugs like that before)
>
> binutils ld is sloppy on some targets but because glibc handles
> symbolic relocs it is just an unnecessary runtime symbol lookup
> there. musl considers this unacceptable linker behaviour: it
> would require half of the dynlinker static linked into every
> static pie unnecessarily.
I don't think we've hit that on x86_64, and it was long ago fixed on
the archs we did hit it on, so I don't think that's what's going on.
But a full readelf -a of the failing binary would quickly reveal if
that's what happened, and would probaby shed light on whatever else if
wrong if not that.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
