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 <jbeul...@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c1723a8118f0d02b01a061095f48e75264b2ca4f commit c1723a8118f0d02b01a061095f48e75264b2ca4f Author: Jan Beulich <jbeul...@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.