[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0

[mintsuki at protonmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31795

--- Comment #38 from mintsuki <mintsuki at protonmail dot com> ---
(In reply to Fangrui Song from comment #37)
> I agree with mintsuki . The "-pie -Ttext-segment=non-zero => ET_EXEC" hack
> should not be needed.
> 
> From https://sourceware.org/pipermail/binutils/2013-December/083381.html
> 
> > Linker sets e_type in ELF header to ET_DYN for -pie -Ttext-segment=0xXXX.
> > When I added -Ttext-segment=0xXXX, one goal was to load
> > small model executable above 4GB on Linux/x86-64, which
> > was done with -pie -Ttext-segment=0xXXX.  But -pie sets
> > e_type in ELF header to ET_DYN and kernel may ignore
> > p_vaddr in ELF header to load ET_DYN binary at a random
> > address.  This patch changes ld to set e_type in ELF header
> > to ET_EXEC if the first PT_LOAD segment has non-zero
> > p_vaddr.  If this is unacceptable as generic ELF change,
> > I can make it specific to x86.
> 
> Was the intention for the following command to load the text segment at an
> address >= 0x600000000000 ?
> 
> ```
> % cat a.c
> #include <stdio.h>
> int main() { printf("%p\n", main); }
> % gcc -pie -Wl,-no-pie a.c -fuse-ld=bfd
> -Wl,--no-relax,-Ttext-segment=0x600000000000 -o a
> % ./a
> 0x600000001139
> % ./a
> 0x600000001139  # no ASLR
> ```
> 
> Changing ET_DYN to ET_EXEC fulfills the address requirement but disables
> ASLR.
> Is it intentional?
> 
> I added `--no-pie` to GNU ld in 2021:
> https://sourceware.org/cgit/binutils-gdb/commit/
> ?id=e8f6c2a5bab10b039a12b69a30a8248c91161e11 , with which we can do the
> following instead. (GNU ld also needs `--no-relax` while lld doesn't).
> 
> ```
> % gcc -pie a.c -fuse-ld=bfd
> -Wl,--no-pie,--no-relax,-Ttext-segment=0x600000000000 -o a
> % ./a
> 0x600000001139
> % ./a
> 0x600000001139
> ```

Thanks for agreeing with me and reopening this bug report.

I appreciate that someone else sees this for the bug that it is, rather than
trying to hand wave the issue away. I hope it will get addressed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.