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

Jan Beulich jbeulich@suse.com
Fri Dec 12 13:14:43 GMT 2025
On 12.12.2025 14:08, Rainer Orth wrote:
>> 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.
> 
> I see.  Initially I had another solution that would at least only affect
> Solaris (or targets that have a similar issue): emulation aliases.  This
> way, gld would silently (i.e. without advertising them in gld -V) accept
> select emulation names and treat them exactly like another one.
> E.g. gld -m elf_i386 wouldn't show up in gld -V, but would be treated as
> another name for -m elf_i386_sol2.
> 
> The patch isn't much larger than the previous one.

Well, if that works (and has no other fallout), why not give it a try?

Jan


More information about the Binutils mailing list