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

Jan Beulich jbeulich@suse.com
Fri Feb 27 09:00:01 GMT 2026


On 27.02.2026 08:46, Fangrui Song wrote:
> On Wed, Feb 25, 2026 at 12:15 AM Fangrui Song <i@maskray.me> wrote:
>>
>> 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.

And hence the test shouldn't fail for (e.g.) this target, but does? That
would be an xfail, wouldn't it?

>> 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
> 
> BTW, I think the cleanest approach for the reloc-section-sym approach
> is to reorganize equ-reloc/redef as a prerequisite patch (as this
> patch does) and then add reloc-section-sym-* tests in the switch block

That's fine with me, it just needs to be sorted which targets truly want
excluding vs which ones need to remain xfail. Those sets may not be all
the same for the different tests, i.e. simply adding your new ones to
the existing switch may not be entirely correct.

>  That said, if you prefer to keep the test structure closer to the
> original, I can instead abandon this patch and adjust the
> reloc-section-sym patch to add the new tests alongside the existing
> ones:
> 
>             setup_xfail "m681*-*-*" "m68hc*-*-*" "xgate-*-*" "vax-*-*" "avr-*-*"
>             run_dump_test redef
>             run_dump_test equ-reloc
>   +         setup_xfail "m681*-*-*" "m68hc*-*-*" "xgate-*-*" "vax-*-*" "avr-*-*"
>   +         run_dump_test "reloc-section-sym-all"
>   +         setup_xfail "m681*-*-*" "m68hc*-*-*" "xgate-*-*" "avr-*-*"
>   +         run_dump_test "reloc-section-sym-internal"
>   +         run_dump_test "reloc-section-sym-none"
> 
> While I think this is ugly,  my primary goal is to get the assembler change in.

I could live with this, if you don't feel like getting the prereq change
into a shape that me or another global maintainer would give their okay
for.

Jan


More information about the Binutils mailing list