[PATCH] ld: testsuite: xfail vers26b3 on Solaris/amd64

[Jan Beulich]

On 19.08.2025 10:39, Rainer Orth wrote:
>> On 19.08.2025 10:25, Rainer Orth wrote:
>>>>>>> I tried that first, but unlike Linux/x86_64, where several of the vers*
>>>>>>> tests XFAIL, on Solaris/amd64 it was only this single one, so all the
>>>>>>> others would XPASS instead.
>>>>>>>
>>>>>>> The fact that the test links just fine with Solaris ld might point to a
>>>>>>> gld issue, though.
>>>>>>>
>>>>>>
>>>>>> R_X86_64_32 can't be used to access the external symbols in
>>>>>> a shared library since 32-bit displacement may not reach the
>>>>>> symbol definition.  How can it work on Solaris?
>>>>>
>>>>> No idea.  However, when reenabling the test on Linux/x86_64, I get the
>>>>> exact same error as on Solaris/amd64, so the issue is obviously the
>>>>> same:
>>>>>
>>>>> ./ld-new: tmpdir/vers26b3.o: relocation R_X86_64_32 against symbol `foo' can not be used when making a shared object; recompile with -fPIC
>>>>
>>>> Yet there lies the question: You say that linking with Solaris'es linker
>>>> works fine. Question is whether that's a bug there (and the resulting image
>>>> is broken), or whether GNU ld has a shortcoming.
>>>
>>> I know.  But this question is different from the handling of the FAIL on
>>> Solaris/amd64.  If the test FAILs in exactly the same way as on
>>> Linux/x86_64, it should be acceptable to xfail it there too as a stopgap
>>> measure to get the test results clean.
>>
>> Yet what to put in the patch description differs. And that matters when it
>> comes to potentially making changes there later on. (I am, btw, not
>> convinced that using XFAIL in such a case is correct. If the test can't
>> possibly work, it should be skipped or marked UNSUPPORTED rather than being
>> XFAILed, imo.)
> 
> true, but the verdict on this is still out until the linker side of the
> issue is investigated more closely...  And in the short term, that's
> more of a cosmetic issue, especially since the ld message right now
> incorrectly states to recompile with -fPIC although that has already
> been done.

Can you show us the code the compiler produces with -fPIC, where said
relocation is in use? If the compiler rightfully emits such a relocation,
then I would agree the ld diagnostic is wrong. If otoh the compiler
produces wrong code, then the ld diagnostic is quite okay, as it assumes
valid incoming code. Depending on that is also whether XFAIL is actually
the right thing to use here (as per my earlier reply).

Jan