[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

Richard Earnshaw <rearnsha at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |INVALID

--- Comment #5 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
(In reply to Julius Werner from comment #4)
> 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? 

No, I'm saying you can't use ADRP for a *weak* symbol reference in position
independent 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.

What documentation?  ARM docs don't say you can use a division instruction for
doing general addition, but clearly you can't...

> 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.

It's all a consequence of the requirements on the binary and the constraints
that imposes.  Building code that is PIC takes some care and consideration of
the operating constraints.  Code, even PIC, needs to be read-only (no dynamic
relocations) and that means that after static linking there must be no
outstanding relocations on the binary.  With weak symbols we don't know until
run-time whether or not the symbol will be defined.  The two constraints are
incompatible with each other if we allow ADRP to reference a weak symbol.  It's
not just weak symbols have this property; symbol pre-emption can have a similar
impact.  The rules for building an ELF image that is workable can and do
restrict which instructions can be used in which contexts.  You as the
programmer have to understand this, just as a compiler has to.

> 
> 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).

But it's not compile-time known.  That's the point.

>  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.

That's not the model implemented in GNU binutils.  Nor is it the model wanted
for normal PIC code.

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