[Bug ld/21532] AArch64: Symbol address inconsistency across compilation units

[jiwang at gcc dot gnu.org]

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

--- Comment #9 from Jiong Wang <jiwang at gcc dot gnu.org> ---
(In reply to Jiong Wang from comment #8)
> Temporarily reopen this bug as the fix was reverted because it will leak
> some PC-relative relocations in while PC-relative support on copy relocation
> elimination is going on as explained at the email.  So this fix itself is
> incomplete.


The PC-relative regression is looks like the following:

   unresolvable R_AARCH64_ADR_PREL_PG_HI21 relocation against symbol
`_ZTIi@@CXXABI_1.3'


The failure was because the symbol "_ZTIi@@CXXABI_1.3" is referenced by both
absoluate relocation types R_AARCH64_ABS_64 and pc-relative relocation types
R_AARCH64_ADR_PREL_PG_HI21.  While The current elfNN_aarch64_check_relocs
implementation only allocate dynrelocs for absoluate relocation types 
R_AARCH64_NN, this caused elfNN_aarch64_adjust_dynamic_symbol missed the
reference of "_ZTIi@@CXXABI_1.3" by R_AARCH64_ADR_PREL_PG_HI21 which is a text
relocation that is read-only in which case we should keep copy relocation.

My understanding of the copy relocation elimination framwork in BFD linker
is we should always allocate dynrelocs for all those relocation types that are
possible to introduce copy relocations, and they are actually relocation types
that will be used to form address of external object in non-PIC executable.

So a complete fix should also fix the current elfNN_aarch64_check_relocs
implementation to:

  * Also allocate dynrelocs for a few pc-relative relocation types which will
    be used to form object address under tiny, small memory model.

    As AArch64 dynamic linker does not support pc-relative relocations,
    we need to alway keep copy relocation for them later in
    adjust_dynamic_symbol if pc_count is not zero to avoid introducing
    runtime relocation for them.

  * For large memory model, AArch64 also use some MOVW_G* relocations to form
    object address under non-PIC mode.  We need to allocate dynrelocs for their
    reference on symbol as well. 

I am testing a fix and will post it after finishing a full test on
binutils/gcc/g++ check plus some big project linking.

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