https://sourceware.org/bugzilla/show_bug.cgi?id=22589
--- Comment #10 from Richard Earnshaw <rearnsha at gcc dot gnu.org> --- (In reply to Szabolcs Nagy from comment #9) > i ran into this again and i think the linker could relax 'adrp xN, weaksym' > into 'mov xN, 0' if weaksym is undefined. Static linker or dynamic? The dynamic linker can't change any code segment during loading, since that would break the code-sharing model used by SVr4-like systems. I don't see how the static linker can know that a dynamically loaded library won't provide a definition at run-time, so that doesn't make a lot of sense to me either. > > link error is not helpful since such code (accessing weak symbols) may be > behind checks and unreachable if the symbol is undefined. > > normally weak syms are accessed via GOT which can be 0 for undef, but in PIC > this depends on a dynamic relocation even for hidden visibility syms. this > does not work in early start code (e.g. *crt1.o) accessing weak, linker > generated symbols (such as __ehdr_start) where the code must not generate > dynamic relocations (since it may be executed before ld.so or static pie > self relocation). if such symbol is potentially undefined then we have a > problem: adrp does not work, GOT does not work, movz does not work. so i > dont see a way to implement > > if (&weaksym != 0) > use(&weaksym); > > logic in the ld.so or static pie start code. i ran into this with the > morello port where there are linker created symbols (__rela_dyn_start) that > are only defined under certain conditions (static exe with no > dynamic-linker) and must be checked and accessed in gcrt1.o that is used in > both pde and pie. -- You are receiving this mail because: You are on the CC list for the bug.
