[Bug gas/25406] [ARM] pcrel relocations referencing STB_GLOBAL symbols are resolved at assembly time

[peter.smith at arm dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=25406

Peter Smith <peter.smith at arm dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |peter.smith at arm dot com

--- Comment #5 from Peter Smith <peter.smith at arm dot com> ---
Just to mention our thoughts from the Arm side for what we'd like to see in GCC
and LLVM. In summary we'd like LLVM to match the GNU behaviour. There is scope
for a better error message in GNU as when the ADR/LDR fixup cannot be resolved
at assembly time.

The relocation ranges for ADR and LDR are tiny, in general they cannot be
expected to reach anything outside the section that they are defined in. There
is no dynamic relocation that can be used to resolve to a preempted definition.

- ADR and LDR should be resolved at assembly time within the same section, even
if it is a global default visibility symbol.
- A specific assembly time error if ADR and LDR if the symbol is defined
outside the same section.
- It is user error if code uses ADR or LDR to a global default visibility
symbol and that symbol is preempted at runtime [1].

There are two possible alternatives:
1.) ADR and LDR to global default visibility symbol is an error message.
2.) ADR and LDR to global default visibility symbol produces a relocation and
the linker gives an error message in a shared context.

Our view is that alternative 1 risks breaking too much legacy code,
particularly in embedded code, which in some cases rebuilding can involve an
expensive revalidation. Option 2 allows the error message to occur only when it
is needed, however the linker error message that would result (relocation
overflow) which would also occur for a cross-section reference is not easy for
the author to track down. With the risk of ADR or LDR being used in a shared
context seen as very low, we'd prefer to keep the existing GCC behaviour and
update LLVM to match.



An example of code that is not suitable for a shared library [1]
.text
 .global foo
 .type foo, %function
foo:
 adr r0, foo // resolved at assembly time to foo in this shared library
 bx lr

 .data
 .word foo // Potential dynamic relocation, to default visibility symbol foo, 
           // could be preempted to point to some other definition of foo, this
           // may result in problems if these definitions need to be the same.

-- 
You are receiving this mail because:
You are on the CC list for the bug.