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

[Rainer Orth]

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.

* 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.

  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