https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #48 from mintsuki <mintsuki at protonmail dot com> --- (In reply to H.J. Lu from comment #47) > (In reply to mintsuki from comment #46) > g. > > > > > > Opt-in to ET_EXEC will be wrong. > > > > Why will it be wrong? What if someone (me) wants to make a PIE that loads at > > It is wrong because -Ttext-segment=0x600000000000 no longer works. > > > a minimum at the specified address, but can be relocated above it? Currently > > ld makes this impossible by simply checking the ELF type, forcing my ELF > > loader to additionally check for the presence of the DF_1_PIE flag to decide > > whether an ELF file is relocatable or not... > > > > ...but Linux doesn't do that, apparently, but instead forces the load > > address to be the one specified, due to the ELF type being ET_EXEC. > > > > Earlier you said I should check DF_1_PIE to determine relocatability... so > > No, that was not what I said. DF_1_PIE can be used to determine if a binary > is PIE. Okay, then how can I make a *relocatable* aka ET_DYN (?) ELF file which is PIE and has a non-0 text segment load address using ld? This is, as far as my knowledge goes, *impossible* using GNU ld.bfd. Why? I can still make an ET_DYN ELF using -shared instead of -pie, but then I have to build using -fPIC rather than -fPIE, as far as I understand. And in any case I don't understand why the limitation. > > > which one is it? If I check for DF_1_PIE then I am not following the same > > behaviour as the Linux ELF loader, which means that I either break from > > Linux's behaviour, or I follow it, but that means that ld will never allow > > me to make an ET_DYN PIE with a non-0 load address. -- You are receiving this mail because: You are on the CC list for the bug.
