https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #7 from mintsuki <mintsuki at protonmail dot com> --- (In reply to H.J. Lu from comment #5) > (In reply to mintsuki from comment #3) > > Also, when generating a shared object with -shared, without -pie, having a > > non-0 base address does not affect the ELF file type, which is always > > You can't load the multiple shared libraries at the overlapping address > range. > > > ET_DYN. If what you just said is true, then why is this the behaviour here > > and not when making a static PIE? > > A testcase? Download and unpack https://github.com/limine-bootloader/limine-c-template/archive/d90875580fb74c3cf075b659c995e4070d265c24.tar.gz In the extracted directory, run "make -C kernel clean all KCC=gcc KLD=ld.bfd". The output kernel is found at "kernel/bin/kernel". The linker script is found at "kernel/linker.ld". So, building this with ld.bfd, the output ELF file type is ET_EXEC, as in the subject of this bug report. Replacing ld.bfd with ld.gold or ld.lld in the command above will generated a static PIE kernel with type ET_DYN and a non-0 base (0xffffffff80000000). ld.bfd is the outlier here. Replacing -pie with -shared at line 73 of "kernel/GNUmakefile" and then rebuilding, as mentioned above, will cause all 3 linkers to (correctly) generate an ET_DYN shared object with the specified non-0 base. -- You are receiving this mail because: You are on the CC list for the bug.
