[Bug gas/27217] aarch64 as Internal error in md_apply_fix at ....../gas/config/tc-aarch64.c:8330.

[cvs-commit at gcc dot gnu.org]

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

--- Comment #20 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot 
gnu.org> ---
The master branch has been updated by Jan Beulich <jbeulich@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c1723a8118f0d02b01a061095f48e75264b2ca4f

commit c1723a8118f0d02b01a061095f48e75264b2ca4f
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Jul 29 09:26:47 2022 +0200

    Arm64: re-work PR gas/27217 fix

    The original approach has resulted in anomalies when . is involved in an
    operand of one of the affected insns. We cannot leave . unresolved, or
    else it'll be resolved at the end of assembly, then pointing to the
    address of a section rather than at the insn of interest. Undo part of
    the original change and instead check whether a relocation cannot be
    omitted in md_apply_fix().

    By resolving the expressions again, equates (see the adjustment of the
    respective testcase) will now be evaluated, and hence relocations
    against absolute addresses be emitted. This ought to be okay as long as
    the equates aren't global (and hence can't be overridden). If a need
    for such arises, quite likely the only way to address this would be to
    invent yet another expression evaluation mode, leaving everything
    _except_ . un-evaluated.

    There's a further anomaly in how transitive equates are handled. In

            .set x, 0x12345678
            .eqv bar, x
    foo:
            adrp    x0, x
            add     x0, x0, :lo12:x

            adrp    x0, bar
            add     x0, x0, :lo12:bar

    the first two relocations are now against *ABS*:0x12345678 (as said
    above), whereas the latter two relocations would be against x. (Before
    the change here, the first two relocations are against x and the latter
    two against bar.) But this is an issue seen elsewhere as well, and would
    likely require adjustments in the target-independent parts of the
    assembler instead of trying to hack around this for every target.

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