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

[Jan Beulich]

On 19.08.2025 11:03, Rainer Orth wrote:
> Hi Jan,
> 
>> 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).
> 
> In fact, I cannot: at least ldd -r complains
> 
> 	tmpdir/vers26a.so =>	 tmpdir/vers26a.so
> 	tmpdir/vers26b1.so =>	 tmpdir/vers26b1.so
> ld.so.1: vers26b3.so.ld: fatal: relocation error: R_AMD64_32: file tmpdir/vers26b3.so.ld: symbol foo: value 0x7fff8cb00830 does not fit
> 
> so the issue is just shifted from a linker error to a runtime (ld.so.1)
> error ;-(
> 
> Seems like bad code indeed.
> 
> That would argue for making the test UNSUPPORTED on both Linux/x86_64
> and Solaris/amd64.

Yes. Let's see what H.J.'s take is.

Jan