Home Original page

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

Rainer Orth ro@CeBiTec.Uni-Bielefeld.DE
Tue Aug 19 09:03:42 GMT 2025 
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.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
More information about the Binutils mailing list