[PATCH] ld: testsuite: xfail ld-elf/compress1a etc. on Solaris/sparcv9 [PR25802]

[Jan Beulich]

On 21.10.2025 09:37, Rainer Orth wrote:
> Hi Jan,
> 
>> On 29.09.2025 14:59, Rainer Orth wrote:
>>> A couple of tests FAIL on Solaris/sparcv9:
>>>
>>> FAIL: ld-elf/compress1a
>>> FAIL: ld-elf/compressed1a
>>> FAIL: ld-elf/eh5
>>> FAIL: --gc-sections with multiple debug sections for a function section
>>>
>>> The symptom is always the same:
>>>
>>> tmpdir/compress1.o:(.debug_info+0x10): relocation truncated to fit: R_SPARC_UA32 against `.text'
>>>
>>> and several more.  However, the tests link just fine with Solaris ld.
>>>
>>> As analysed in the PR, this patch xfail's the first three and runs the
>>> last with Ttext=0x0x80000000 (the address used in
>>> /usr/lib/ld/sparcv9/map.below4G) to allow the link to succeed.
>>
>> I'm not very happy about such XFAILs, and other than Nick had requested
>> in the bug report they're also entirely uncommented. Plus as per comment
> 
> sorry I missed that, probably in part because none of the existing xfails
> had comments.
> 
>> 9 there (post-dating the patch submission afaict), the problem looks
>> like it wants dealing with differently anyway.
> 
> Not really: I've since learned that Solaris ld linking the tests without
> errors (actually only the first three ones, the last is about R_SPARC_32
> instead of R_SPARC_UA32 and fails with both linkers) is a historical
> oversight going 30 years back.  While I was able to mimic that behaviour
> in bfd as described in the PR, Ali Bahrami strongly advised against
> following Solaris ld behaviour here which violates the SPARC psABI.
> 
> To summarize the situation:
> 
> * Since .eh_frame needs to read-write on Solaris except Solaris/amd64 as
>   described in gas/config/te-solaris.h, it lands in the data segment, so
>   the R_SPARC_UA32 and R_SPARC_32 relocations in .eh_frame against .text
>   are out of range.  Thus the "relocation truncated to fit" errors are
>   benign.
> 
> * One could avoid those by linking the affected tests with
>   -Ttext=0x80000000, matching Solaris /usr/lib/ld/map.below4G.
> 
> * There are two options to handle this:
> 
> ** Just xfail all four affected tests on sparcv9-*-solaris2* since the
>    error is correct and nothing can be done it about without special
>    handling (which wouldn't be used in the wild).
> 
> ** I found a way to apply the linker flag above to only those four tests
>    on Solaris/sparcv9:
> 
> Define a new proc in ld-lib.exp
> 
> # Return ldflags to load 64-bit Solaris/SPARC programs below 4 GB.  This
> # matches /usr/lib/ld/map.below4G.
> # Applies to both sparcv9 and amd64, but only needed on SPARC.
> proc sol2sparcv9_below4G_ldflags { } {
>     if [istarget sparcv9*-*-solaris2*] {
> 	return "-Ttext=0x80000000"
>     }
>     return ""
> }
> 
> and apply it to all for affected tests like this:
> 
> diff --git a/ld/testsuite/ld-elf/compress1a.d b/ld/testsuite/ld-elf/compress1a.d
> --- a/ld/testsuite/ld-elf/compress1a.d
> +++ b/ld/testsuite/ld-elf/compress1a.d
> @@ -1,6 +1,7 @@
>  #source: compress1.s
>  #as: --compress-debug-sections
> -#ld: -e func_cu2
> +# See PR ld/25802 for the Solaris/sparcv9 handling.
> +#ld: -e func_cu2 [sol2sparcv9_below4G_ldflags]
> 
> since you can call arbitrary Tcl procs with "#ld: ".  While this works
> as expected, it seems completely overengineered to me.
> 
> Which variant should I use then?

XFAILs with comments (and more extensive explanation in the patch description)
would seem best to me.

Jan