[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250301173959.GS1827@brightrain.aerifal.cx>
Date: Sat, 1 Mar 2025 12:39:59 -0500
From: Rich Felker <dalias@...c.org>
To: Dmitry Vyukov <dvyukov@...gle.com>
Cc: Sertonix <sertonix@...teo.net>, musl@...ts.openwall.com, nsz@...t70.net
Subject: Re: Support for -static-pie relocations
On Sat, Mar 01, 2025 at 06:03:24PM +0100, Dmitry Vyukov wrote:
> RIght, sorry.
>
> I checked out the latest HEAD c47ad25ea3b484e10326f933e927c0bc8cded3da.
> Standard build: ./configure --enable-debug && make
> arch x86_64
>
> Reproducible with both (standard Debian builds):
> $ clang --version
> Debian clang version 16.0.6 (27+build3)
> $ ld -v
> GNU ld (GNU Binutils for Debian) 2.43.1
> $ clang /tmp/test.c lib/libc.a -O2 -g -static-pie && ./a.out
> Segmentation fault (core dumped)
>
> and
> $ gcc -v
> gcc version 14.2.0 (Debian 14.2.0-3+build4)
> $ gcc /tmp/test.c lib/libc.a -O2 -g -static-pie && ./a.out
> Segmentation fault (core dumped)
If you're going to link as PIE, all source files need to be compiled
as PIE-compatible. You're missing -fPIE unless that's already default
on your toolchains.
> Relocations are mostly rip-relative except for global vars that
> contain pointers:
>
> $ readelf -r ./a.out
> Relocation section '.rela.dyn' at offset 0x350 contains 11 entries:
> Offset Info Type Sym. Value Sym. Name + Addend
> 000000003e48 000000000008 R_X86_64_RELATIVE 11a0
> 000000003e50 000000000008 R_X86_64_RELATIVE 1160
> 000000003e58 000000000008 R_X86_64_RELATIVE 4020
> 000000003e60 000000000008 R_X86_64_RELATIVE 4380
> 000000003fd8 000000000008 R_X86_64_RELATIVE 3e68
> 000000004008 000000000008 R_X86_64_RELATIVE 4008
> 000000004010 000000000008 R_X86_64_RELATIVE 4020
> 000000004038 000000000008 R_X86_64_RELATIVE 19ca
> 000000004068 000000000008 R_X86_64_RELATIVE 19f5
> 000000004070 000000000008 R_X86_64_RELATIVE 19ed
> 000000004078 000000000008 R_X86_64_RELATIVE 41d0
Those are all fine.
> > Relocations are processed in the crt entry point before
> > __libc_start_main is reached. The relevant code is ldso/dlstart.c.
>
> Am I linking musl somehow incorrectly (need to do something with crt)?
>
> My entry function calls __libc_start_main:
>
> Dump of assembler code for function _start:
> 0x00007ffff7ffb0c0 <+0>: xor %ebp,%ebp
> 0x00007ffff7ffb0c2 <+2>: mov %rdx,%r9
> 0x00007ffff7ffb0c5 <+5>: pop %rsi
> 0x00007ffff7ffb0c6 <+6>: mov %rsp,%rdx
> 0x00007ffff7ffb0c9 <+9>: and $0xfffffffffffffff0,%rsp
> 0x00007ffff7ffb0cd <+13>: push %rax
> 0x00007ffff7ffb0ce <+14>: push %rsp
> 0x00007ffff7ffb0cf <+15>: xor %r8d,%r8d
> 0x00007ffff7ffb0d2 <+18>: xor %ecx,%ecx
> 0x00007ffff7ffb0d4 <+20>: lea -0x4b(%rip),%rdi #
> 0x7ffff7ffb090 <main>
> 0x00007ffff7ffb0db <+27>: addr32 call 0x7ffff7ffb3fa <__libc_start_main>
> => 0x00007ffff7ffb0e1 <+33>: hlt
>
>
> I don't see any static libs in musl build that include _start symbol...
_start comes from one of the *crt1.o files in the library directory
(/usr/lib on a normal system wide install; your cross lib dir for
cross compiles). In the case of static pie, the compiler driver (clang
or gcc command) should be pulling rcrt1.o.
The above asm dump does not look like any variant of the musl crt
start files. Are you perhaps doing this on a glibc-based host and just
trying to link musl as a static library? That's not expected to work.
You need to either use a musl-targeting cross toolchain or the
musl-gcc wrapper (but the wrapper is only for minimal/evaluation type
uses and might not support static pie.
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.
