On 7/17/25 10:22, Jan Beulich wrote: > On 17.07.2025 09:32, Yann Sionneau wrote: >> Hello Demi Marie, Jan, Nick, all, >> >> Thank you Demi Marie for bringing this topic on the mailing list. >> >> I discussed it a bit with Jan on Matrix but the situation is not pretty, >> there is no clean solution that stands out easily. >> >> As Jan said, it seems .reloc is meant to be discardable, so we can't >> blame binutils LD for putting it: >> >> https://github.com/bminor/binutils-gdb/commit/25c80428af3311e761c87d8f706596b9701602ec#diff-078cf751467928c038996b40073a682425712b9b01182424e68cf18fb08a75b5R953-R977 >> >> And we can't obviously blame the loaders for honoring this flag. >> >> Most reasonable solution indeed would be to ask binutils to add a link >> flag to say "please do not put the DISCARDABLE flag on the .reloc section" >> >> I'm adding Nick Clifton from binutils in CC so that he can comment on >> this possible outcome or any other possible solution. >> >> In the mean time, while waiting for a solution to emerge (and be merged, >> and released) what do we do? >> >> Do we put some hack in Xen build Makefiles so that xen.efi is >> post-processed to strip this bit? >> >> This could be the temporary solution. > > As indicated - I don't think this is just a temporary solution. Beyond Xen, > I simply don't see value in adding a linker flag (which then, sooner or > later, llvm would also need to support just for Xen). The question rather > is how to make the Xen side hack as little hacky as possible, without > relying on the fragile behavior of objcopy. > > Jan >
Ok I didn't understand your previous answer, it's more clear now, thank you. Would you consider using a tool like this less fragile than objcopy: https://github.com/fallen/keeprelocs ? Regards, PS: sorry for earlier top posting, my Thunderbird was badly configured (new computer). -- Yann Yann Sionneau | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech
