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

[H.J. Lu]

On Tue, Aug 19, 2025 at 2:03 AM Rainer Orth <ro@cebitec.uni-bielefeld.de> 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.
>

UNSUPPORTED is OK.

-- 
H.J.