[Bug ld/22589] aarch64: adrp relocation gets filled with non-zero address for undefined weak symbol

[rearnsha at gcc dot gnu.org]

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.