On Mon, 13 Feb 2023 at 23:23, Marvin Häuser <mhaeu...@posteo.de> wrote: > > > On 13. Feb 2023, at 22:59, Ard Biesheuvel <a...@kernel.org> wrote: > > No, the only reason for adding -fpie here is to ensure that statically > initialized CONST pointers are emitted into .data.rel.ro and not into > .rodata, as this is under the control of the compiler. Although, > thinking about this, I wonder if we need to pass this to the linker > for codegen under LTO as well. But the PIE link itself should be > unnecessary here. > > > Oh, what fun. For some reason I thought it would be unsafe to specify -fpie > but not -pie, but considering PIE relocs are ignored either way, this > actually makes perfect sense. Sorry! About that last part, the docs say: "It > is recommended that you compile all the files participating in the same link > with the same options and also specify those options at link time." [1], so > good catch! > > [1] https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options >
Yeah, but come to think of it, we pass the CC flags to the linker, so this should be covered. > But what about -fno-plt? > That doesn't make a difference in codegen on AArch64 - the same BL instruction is emitted along with the same type of relocation, and it is left up to the linker whether or not a PLT entry is emitted, and I don't think it will ever do that when generating a fully linked binary without -pie. > > It will if you pass -pie to the linker, which is why I would prefer to > avoid that. The main issue IIRC is that the emit-relocs section does > not cover the entries in the GOT table that also require relocation, > and are only covered by the PIE .rela section. For AArch64, I added > relaxation logic to GenFw to actually patch the instructions instead, > which is always possible given the absence of dynamic linking. > (d2687f23c909475d80cef32cdf9a5d121f0a9ae6, > 7b8f69d7e10628d473dd225224d8c2122d25a38d) > > > Yes, seen, very nice. I do wonder though why GOT entries are generated in the > first place when symbols are all local and data is within the PC-addressable > range. Just today, for a X64 build, I actually saw Clang relax a GOT > reference to __stack_chk_guard itself. > Yeah there are some strange corner cases, but in general, all symbol references are relative - it is precisely the 'special' symbol references that the compiler generates internally that sometimes get this wrong. > > This means that we don't have to care about compiler generated symbol > references, and so the relocs emitted by emit-relocs are sufficient, > and the additional ones emitted into .rela are unused anyway. The only > remaining absolute references are the ones resulting from statically > initialized globals, and those will either be in .data or in > .data.rel.ro (if -fpie is being used) > > > Right. thank you. > > Best regards, > Marvin > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#100142): https://edk2.groups.io/g/devel/message/100142 Mute This Topic: https://groups.io/mt/96937498/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-