[PATCH] gas/testsuite: adjust equ-reloc and redef

[Fangrui Song]

On Tue, Feb 24, 2026 at 11:07 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 25.02.2026 06:53, Fangrui Song wrote:
> > equ-reloc passes on all ELF target except alpha/hppa where
> > .set is a machine directive rather than an .equ alias.
> >
> > For redef, remove hppa, iq2000, and mips from the exclusion list since
> > they pass.  Move avr, m681, m68hc, vax, and xgate into the exclusion
> > list since their tc_fix_adjustable always prevents section symbol
> > conversion.
>
> Looking at just the first one, avr_fix_adjustable() has a comment very
> much suggesting that xfail is correct to use there. Looking over the
> set of "excluded" reloc types in tc_m68k_fix_adjustable() gives the
> impression (to me) that "ordinary" relocs can be converted, so again
> xfail looks appropriate. I didn't look further.

I think we should first define what tc_fix_adjustable behaviors warrant XFAIL.

PLT-generating and GOT-generating relocations, for example, may
require dynamic relocations where the symbol identity is significant,
so they must reference the original symbol.
Similarly, TLS relocations cannot be adjusted.
For other relocation types, it is completely ok to skip adjustment as
much as possible.
The downside, excessive internal symbols relative to SHF_STRINGS and
DWARF sections (and jump targets in text sections), is minor and not
something I'd call a bug to fix.

riscv and loongarch use `#define tc_fix_adjustable(fixp) 0`. avr uses
a more nuanced rule that only prevents code sections and non-merge
sections (to support linker relaxation).
I don't think penalizing it with XFAIL is appropriate.

tc_m68k_fix_adjustable looks correct to me - it excludes
PLT-generating, GOT-generating, and TLS relocations, and allows
adjustment for everything else.

Many of the excluded targets are probably embedded - they might not
have PLT/GOT/TLS relocations at all, so they can adjust most
relocation types.
If a target supports linker relaxation and suppresses many relocation
types for linker convenience, that's a reasonable design choice, not
an assembler deficiency.

> >  Sort the remaining entries alphabetically.
>
> With the previously mentioned issue (vax vs xgate) still being there.

Ack

> Jan