[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0
https://sourceware.org/bugzilla/show_bug.cgi?id=31795 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #1 from H.J. Lu --- It is done to ensure that PIE is loaded at the specific address which may be required for functional, performance or security purposes. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0
https://sourceware.org/bugzilla/show_bug.cgi?id=31795 --- Comment #2 from mintsuki --- (In reply to H.J. Lu from comment #1) > It is done to ensure that PIE is loaded at the specific address which may > be required for functional, performance or security purposes. This does not match what all the other major linkers do (LLD, gold). It also isn't properly documented anywhere that I could find. Additionally, why would someone generate a PIE just for it to be loaded *always* at the same specified address? What is the use case? >From what I know, if a PIE has a specific non-0 load address, it should be taken as a hint or preferred load address, but then the program loader should be able to apply any slide to it as it sees fit. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0
https://sourceware.org/bugzilla/show_bug.cgi?id=31795 --- Comment #3 from mintsuki --- 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 ET_DYN. If what you just said is true, then why is this the behaviour here and not when making a static PIE? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0
https://sourceware.org/bugzilla/show_bug.cgi?id=31795 --- Comment #4 from H.J. Lu --- (In reply to mintsuki from comment #2) > (In reply to H.J. Lu from comment #1) > > It is done to ensure that PIE is loaded at the specific address which may > > be required for functional, performance or security purposes. > > This does not match what all the other major linkers do (LLD, gold). It also > isn't properly documented anywhere that I could find. Additionally, why > would someone generate a PIE just for it to be loaded *always* at the same > specified address? What is the use case? A program may work properly only when it is loaded above 4GB address. > From what I know, if a PIE has a specific non-0 load address, it should be > taken as a hint or preferred load address, but then the program loader > should be able to apply any slide to it as it sees fit. If a PIE doesn't care where to load, set the load address to 0. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0
https://sourceware.org/bugzilla/show_bug.cgi?id=31795 --- Comment #5 from H.J. Lu --- (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? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0
https://sourceware.org/bugzilla/show_bug.cgi?id=31795 --- Comment #6 from mintsuki --- (In reply to H.J. Lu from comment #4) > (In reply to mintsuki from comment #2) > > (In reply to H.J. Lu from comment #1) > > > It is done to ensure that PIE is loaded at the specific address which may > > > be required for functional, performance or security purposes. > > > > This does not match what all the other major linkers do (LLD, gold). It also > > isn't properly documented anywhere that I could find. Additionally, why > > would someone generate a PIE just for it to be loaded *always* at the same > > specified address? What is the use case? > > A program may work properly only when it is loaded above 4GB address. Yes, and I guess that could be explicitly specified as the functioning of a non-0 load address. But that doesn't mean the program needs to always be loaded at the specific load address. For example, my kernel's load address is 0x8000, aka the top 2GiB of address space, but it can be relocated to anywhere in the range from there to the top of the address space (as long as it fits), for things like, for example, KASLR. Setting the load address to 0 works, the bootloader can relocate the kernel to at or above 0x8000, but this makes debugging with KASLR disabled more annoying as one has to subtract the slide from addresses passed to addr2line, or tell GDB about the slide. > > > From what I know, if a PIE has a specific non-0 load address, it should be > > taken as a hint or preferred load address, but then the program loader > > should be able to apply any slide to it as it sees fit. > > If a PIE doesn't care where to load, set the load address to 0. See above. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0
https://sourceware.org/bugzilla/show_bug.cgi?id=31795 --- Comment #7 from mintsuki --- (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 (0x8000). 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.
[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0
https://sourceware.org/bugzilla/show_bug.cgi?id=31795 --- Comment #8 from H.J. Lu --- (In reply to mintsuki from comment #7) > (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? > I was asking a testcase of static PIE where ELF type wasn't EXEC when a load address was specified. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0
https://sourceware.org/bugzilla/show_bug.cgi?id=31795 --- Comment #9 from H.J. Lu --- (In reply to mintsuki from comment #6) > (In reply to H.J. Lu from comment #4) > > (In reply to mintsuki from comment #2) > > > (In reply to H.J. Lu from comment #1) > > > > It is done to ensure that PIE is loaded at the specific address which > > > > may > > > > be required for functional, performance or security purposes. > > > > > > This does not match what all the other major linkers do (LLD, gold). It > > > also > > > isn't properly documented anywhere that I could find. Additionally, why > > > would someone generate a PIE just for it to be loaded *always* at the same > > > specified address? What is the use case? > > > > A program may work properly only when it is loaded above 4GB address. > > Yes, and I guess that could be explicitly specified as the functioning of a > non-0 load > address. > But that doesn't mean the program needs to always be loaded at the specific > load address. > For example, my kernel's load address is 0x8000, aka the top > 2GiB of address > space, but it can be relocated to anywhere in the range from there to the > top of the > address space (as long as it fits), for things like, for example, KASLR. > > Setting the load address to 0 works, the bootloader can relocate the kernel > to at or above > 0x8000, but this makes debugging with KASLR disabled more > annoying as one has > to subtract the slide from addresses passed to addr2line, or tell GDB about > the slide. GDB has no problems to debug PIE with load address == 0. Is this issue specific to kernel? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0
https://sourceware.org/bugzilla/show_bug.cgi?id=31795 --- Comment #10 from mintsuki --- (In reply to H.J. Lu from comment #8) > (In reply to mintsuki from comment #7) > > (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? > > > > I was asking a testcase of static PIE where ELF type wasn't EXEC when a load > address was specified. There is no such case for ld.bfd. I never said there was, sorry if I wasn't clear enough. That said, lld and gold both allow for such case as previously mentioned. What I believe the bug consists of is the behaviour of ld.bfd not aligning with the other linkers. I think it makes perfect sense for an ET_DYN static PIE with non-0 load address to exist, as previously mentioned, and I believe the bug is ld.bfd not allowing this. If this is policy, then I believe it should be properly documented somewhere, if it wasn't already, and then ld.gold (as part of GNU binutils) should be changed to match ld.bfd's behaviour. Though I hope this isn't done as I consider ld.gold's (and LLD's) behaviour to be the preferrable one. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0
https://sourceware.org/bugzilla/show_bug.cgi?id=31795 --- Comment #11 from H.J. Lu --- (In reply to mintsuki from comment #10) > If this is policy, then I believe it should be properly documented Updating document won't solve your debugging issue. Why does GDB have no issues with PIE in user space? > somewhere, if it wasn't already, and then ld.gold (as part of GNU binutils) > should be changed to match ld.bfd's behaviour. Though I hope this isn't done > as I consider ld.gold's (and LLD's) behaviour to be the preferrable one. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0
https://sourceware.org/bugzilla/show_bug.cgi?id=31795 --- Comment #12 from mintsuki --- (In reply to H.J. Lu from comment #11) > (In reply to mintsuki from comment #10) > > > If this is policy, then I believe it should be properly documented > > Updating document won't solve your debugging issue. Why does GDB have > no issues with PIE in user space? I do not have a debugging issue, I am merely asking why ld.bfd is refusing to generate static PIEs with type ET_DYN when the base address is non-0, while all the other linkers generate them fine. If the solution is to just never do that, I can easily instead generate a shared object instead of a PIE, with a non-0 base, as that is accepted by ld.bfd just fine, and by lld and gold. Why doesn't ld.bfd allow generating a PIE with a non-0 base when lld and gold allow that? Why is it not possible to change ld.bfd's behaviour to match lld and gold? Where in the ELF spec and/or binutils documentation is it explained that PIE ELFs should only ever have a 0 load address? Why this? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0
https://sourceware.org/bugzilla/show_bug.cgi?id=31795 H.J. Lu changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-05-25 Status|UNCONFIRMED |WAITING --- Comment #13 from H.J. Lu --- Does PIE with zero load address cause any real problems for you? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0
https://sourceware.org/bugzilla/show_bug.cgi?id=31795 --- Comment #14 from mintsuki --- (In reply to H.J. Lu from comment #13) > Does PIE with zero load address cause any real problems for you? Why not just answer the question? Whether it causes real problems for me or not should be irrelevant to the question I am posing, which I won't repeat again as I already did several times over. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0
https://sourceware.org/bugzilla/show_bug.cgi?id=31795 --- Comment #15 from H.J. Lu --- Here is the original discussion: https://lore.kernel.org/all/came9roojvfj-r3zbwpecpiulfcdrxprpayzcammxf3k7014...@mail.gmail.com/T/#m2cfa035c82e32ca865ec0f1c352b14470dcc7f39 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0
https://sourceware.org/bugzilla/show_bug.cgi?id=31795 --- Comment #16 from mintsuki --- (In reply to H.J. Lu from comment #15) > Here is the original discussion: > > https://lore.kernel.org/all/CAMe9rOoJvfJ- > r3zbwpecpiulfcdrxprpayzcammxf3k7014...@mail.gmail.com/T/ > #m2cfa035c82e32ca865ec0f1c352b14470dcc7f39 Okay, thank you. Then this seems like it was done as a hack to get the Linux kernel to cooperate, from a quick skimming. I do not agree with that change, but I guess my opinion hardly matters, especially not 10 years after it was done. I hope this can be reverted, then, or that a linker flag is added to allow this, as from all I can gather, this does not go against spec. Especially since shared objects (non-PIE) can be made with arbitary load addresses. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0
https://sourceware.org/bugzilla/show_bug.cgi?id=31795 H.J. Lu changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED Target Milestone|--- |2.43 --- Comment #17 from H.J. Lu --- Fixed in 2.43 by: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=0daa17bf187cebd5b200f4fd5405cc55e75c391f -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0
https://sourceware.org/bugzilla/show_bug.cgi?id=31795 --- Comment #18 from mintsuki --- (In reply to H.J. Lu from comment #17) > Fixed in 2.43 by: > > https://sourceware.org/git/?p=binutils-gdb.git;a=commit; > h=0daa17bf187cebd5b200f4fd5405cc55e75c391f Thank you very much! I'll just finish off by saying that, while I appreciate this being documented, I would've still preferred the behaviour to be reverted to the previous one, the same as lld and gold. Is there a chance that this will ever be done? It doesn't seem to be an issue for lld and gold, but maybe those aren't used enough and as much as ld.bfd to know... Anyways thanks again. -- You are receiving this mail because: You are on the CC list for the bug.
