[PATCH] x86/Solaris: address two ld test FAILs

[Jan Beulich]

On 12.12.2025 13:52, Rainer Orth wrote:
>>> I've come up with the following solution so far: since the output of gld
>>> -V is equivalent irrespective of the emulation specified
>>>
>>> $ gld -m elf_x86_64_sol2 -V
>>> GNU ld (GNU Binutils) 2.45.50.20251126
>>>   Supported emulations:
>>>    elf_i386_sol2
>>>    elf_x86_64_sol2
>>> $ gld -m elf_i386_sol2 -V
>>> GNU ld (GNU Binutils) 2.45.50.20251126
>>>   Supported emulations:
>>>    elf_i386_sol2
>>>    elf_x86_64_sol2
>>>
>>> (except for the ordering), there's little point of heeding the emulation
>>> *in this particular case* at all.  If we ignore -m with -V, the above
>>> continues to work.  Implementing this is a bit ugly since the -m option
>>> is handled separately very early on, way before -V is checked for.  I've
>>> come up with the following:
>>>
>>>
>>>
>>> to address this.  I have no idea if this is acceptable, but it would
>>> avoid the issue above nicely in a minimally intrusive way.
>>
>> If our testsuite uses -V to determine emulations, why would others not do
>> so as well? IOW faking the the -V output looks like a bad idea to me.
> 
> You misread: -V output stays *exactly* the same as I'd described in a
> follow-up: not even the ordering differs in any way.  Only -V -m <some
> unsupported emulation> doesn't error out any longer but provides the
> same output as without -m <emul>.

But that's the point: Without elf_i386 built in, this

set status [catch "exec $LD -V -melf_i386" got]

will simply fail. But the problem with the testcase is that the command
succeeds, and hence the test is run (and then fails because libbfd doesn't
know the target asked for). You making the command succeed another way
won't change the outcome of the actual test. The -V here, aiui, isn't to
actually have the linker output all emulations, but to allow probing the -m
option without actually initiating an attempt to link anything.

Jan