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

[H.J. Lu]

On Tue, Aug 19, 2025 at 4:24 AM Rainer Orth <ro@cebitec.uni-bielefeld.de> wrote:
>
> Hi Jan,
>
> > 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.
>
> fine.  In the meantime, I've looked into the UNSUPPORTED route in more
> detail.  The result is disturbing in some ways:
>
> * The error on Linux/x86_64 and Solaris/amd64 is the same, so the two
>   should be treated the same (unsupported), unless it's discovered that
>   there's a bug elsewhere.
>
> * However, when xfail'ing the tests when pic is set to yes for
>   Solaris/amd64, too, , a serious error in (at least) vers.exp is
>   revealed: those patches that just PASSed on Solaris/amd64 before
>   (unlike Linux/x86_64) are still marked as XFAIL and never run.  The
>   xfail proc just emits the "XFAIL: <testname>" message and does nothing
>   more (i.e. the test is never run).  What should happen instead is
>   alway run the test; if it fails mark the test XFAIL, if it PASSes
>   unexpectedly, mark it XPASS instead.  The current behaviour/use is
>   blatently wrong.

We can change them to UNSUPPORTED.

> * Besides, as I remembered, multilib testing in binutils is
>   fundamentally broken.  When running the ld testsuite with a site.exp
>   that enables both 32 and 64-bit testing, ld.log shows e.g. when
>   testing vers1 with -m64:
> gcc  -B/var/gcc/binutils/i386/obj/binutils/ld/tmpdir/ld/ -I/vol/src/gnu/binutils/hg/master/local/ld/testsuite/ld-elfvers -g -O2 -fno-sanitize=all -fno-sanitize=all  -m64  -S -fpic -fno-sanitize=all -fno-lto  -c /vol/src/gnu/binutils/hg/master/local/ld/testsuite/ld-elfvers/vers1.c -o tmpdir/vers1.s
> /var/gcc/binutils/i386/obj/binutils/ld/../gas/as-new   -I/vol/src/gnu/binutils/hg/master/local/ld/testsuite/ld-elfvers   -mx86-used-note=no -o tmpdir/vers1.o  tmpdir/vers1.s
> tmpdir/vers1.s: Assembler messages:
> tmpdir/vers1.s:35: Error: `pushq' is only supported in 64-bit mode
> tmpdir/vers1.s:41: Error: bad register name `%rsp'
> tmpdir/vers1.s:47: Error: `popq' is only supported in 64-bit mode
>
>   i.e. while gcc is invoked with -m64, the as-new invocation lacks the
>   corresponding --64, thus erroring out on 64-bit code.  So either the
>   assembly and linking should be done with gcc -B.../ to have the
>   compiler pass the appropriate multilib options, alternative have the
>   testsuite pass them directly instead (second-guessing the compiler and
>   requiring major changes), or declare multilib testing of binutils
>   unsupported.  While this works very well over in gcc, apparently
>   binutils doesn't have this scenario in mind.

That is true.  In binutils, we are trying to test all supported modes if
possible.  Many i386 tests have explicit --32 as option and -m elf_i386
linker options so that they will run with x86-64 binutils build.  It works
if only assembler and linker are used.

>   All of this would require major surgery to the binutils testsuite, so
>   for the time being I decided to remove the previous is_elf64 test
>   since that scenario (testing 32-bit binutils with -m32 and -m64) is
>   pointless.
>
> I'll post the resulting v2 patch immediately.  We could of course wait
> for H.J.'s analysis before doing anything further with this testcase,
> though.
>
>         Rainer
>
> --
> -----------------------------------------------------------------------------
> Rainer Orth, Center for Biotechnology, Bielefeld University
>
>


-- 
H.J.