https://sourceware.org/bugzilla/show_bug.cgi?id=22589
Julius Werner <jwerner at chromium dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|INVALID |---
--- Comment #4 from Julius Werner <jwerner at chromium dot org> ---
Hi Richard,
Sorry, I can't quite follow your argumentation. Are you trying to say that it's
not legal to use the ADRP instruction in position-dependent code? I'm not
really sure what you're basing that assumption on... I can't find anything to
that effect in any of the official ARM documentation and specs. The instruction
may be useful for position-independent code and often used by compilers to this
effect, yes, but that doesn't mean that this is the only valid use for it and
that it isn't allowed for anything else (unless ARM explicitly specified it
like that, which to my knowledge they didn't). If I'm hand-writing assembly and
I want to use the instruction in a way that is compliant with the spec, I think
binutils should accept and link that correctly.
FWIW, this instruction is useful for any load from a compile-time-known address
in position-dependent code where the address is guaranteed to be less than 4GB
away from the program counter (but may be further away than the 32KB
addressable directly by an LDR (immediate) instruction). This is a pretty
common use case for firmware and embedded applications which often use a 1:1
virtual to physical mapping and only need to operate on the DRAM and MMIO
addresses within 0 and 4GB. It's more compact than the LDR <reg>, =<symbol>
mnemonic which translates into 12 bytes of code (compared to 8 bytes for ADRP
and a normal LDR).
I understand that there are cases where the instruction could not output 0
(i.e. if the PC is above 4GB), and I agree that linking should fail with a
relocation overflow in that case. But for cases where it does fit, I think it's
clearly more correct to output an instruction that results in 0 rather than
whatever it's doing right now (which is clearly just wrong, one way or
another). See also my earlier post about how it works perfectly fine for a
defined symbol with value 0. It makes absolutely no sense that this should give
a different result than an undefined weak symbol, they both resolve to exactly
the same address.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
