[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250301161039.GU2724612@port70.net>
Date: Sat, 1 Mar 2025 17:10:39 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: Dmitry Vyukov <dvyukov@...gle.com>
Cc: musl@...ts.openwall.com
Subject: Re: Support for -static-pie relocations
* 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.
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.
