meaning of supports_gnu_unique

[Jan Beulich]

On 28.03.2026 01:45, Alan Modra wrote:
> On Fri, Mar 27, 2026 at 08:42:33AM +0100, Jan Beulich wrote:
>> On 27.03.2026 00:27, Alan Modra wrote:
>>> On Thu, Mar 26, 2026 at 03:35:55PM +0100, Jan Beulich wrote:
>>>> may I ask what the purpose is of this predicate used by the testsuite?
>>>> By its name I would in particular expect it to cover the
>>>> %gnu_unique_object symbol type (supported by the comment there), but as
>>>> demonstrated by ld-unique/unique failing for arm-unknown-linux-gnu there
>>>> must be something I'm missing.
>>>
>>> I don't see any fails on my cross builds of arm-linux-gnueabi..
>>
>> That one's fine indeed. The one I named (shorthand arm-linux) isn't.
>>
>>> Maciej was the original author of that function.  I extracted out
>>> supports_gnu_osabi, prior to which the comment for supports_gnu_unique
>>> said:
>>>
>>> # True if the ELF target supports STB_GNU_UNIQUE with the ELF header's
>>> # OSABI field set to ELFOSABI_GNU.
>>> #
>>> # This generally depends on the target OS only, however there are a
>>> # number of exceptions for bare metal targets as follows.  The MSP430
>>> # and Visium targets set OSABI to ELFOSABI_STANDALONE and cannot
>>> # support STB_GNU_UNIQUE.  Likewise non-EABI ARM targets set OSABI to
>>> # ELFOSABI_ARM, and TI C6X targets to ELFOSABI_C6000_*.  Finally
>>> # rather than `bfd_elf_final_link' a number of targets use
>>> # `_bfd_generic_final_link', which does not support STB_GNU_UNIQUE
>>> # symbol binding causing assertion failures.
>>> #
>>
>> The ELFOSABI_ARM aspect was even mentioned there (and still is in
>> today's form of the comment). If the comment is correct, the
>> *-*-gnu* pattern used in supports_gnu_osabi would need amending to
>> exclude the target above. But: How can *-*-*gnu* not be a GNU target?
>> What would the "gnu" in there indicate then?
> 
> I think you should view supports_gnu_unique and supports_gnu_osabi in
> context as testsuite support, rather than as definitive for gnu
> targets.  Yes, I agree that arm-linux-gnu should be excluded from
> supports_gnu_osabi.

I'm testing the change reproduced at the bottom.

> If you take a look at ld-unique/unique.exp you'll see tests that check
> for readelf output of OSABI "UNIX GNU", ie. ELFOSABI_GNU.  Other
> values of OSABI may well support the various gnu object file
> extensions.
> 
>> Judging from the comments, I would have expected tic6x to have a
>> similar issue, but I haven't observed such in practice. This looks to
> 
> Yes, tic6x is excluded from testing in ld-unique/unique.exp.

Right, just that here I'm after ...

>> be a result of the assembler only ever using (OSABI-generic) targets
>> which bfd/config.bfd installs as secondary ones.

... assembler testing.

Jan

testsuite: supports_gnu_osabi vs Arm

Arm is yet more special than the function presently expresses: Even
targets with "gnu" in the name (e.g. arm-unknown-linux-gnu) aren't
ELFOSABI_GNU. Handle Arm first, and drop other Arm special casing in
exchange.

--- a/binutils/testsuite/lib/binutils-common.exp
+++ b/binutils/testsuite/lib/binutils-common.exp
@@ -234,11 +234,17 @@ proc match_target { target } {
 # testcases will generally need to exclude tic6x or use a -m option.)
 #
 proc supports_gnu_osabi {} {
+    if { [istarget arm*-*-*] } {
+	if { [istarget arm*-*-*eabi*] } {
+	    return 1
+	}
+	return 0
+    }
     if { [istarget *-*-gnu*]
 	 || [istarget *-*-linux*]
-	 || ( [istarget *-*-*bsd*] && ![istarget arm*-*-netbsd*] )
+	 || [istarget *-*-*bsd*]
 	 || [istarget *-*-lynxos]
-	 || ( [istarget *-*-nto*] && ![istarget arm*-*-*] )
+	 || [istarget *-*-nto*]
 	 || [istarget *-*-irix*]
 	 || [istarget *-*-*eabi*]
 	 || [istarget *-*-rtems*] } {
@@ -250,8 +256,7 @@ proc supports_gnu_osabi {} {
     if { ![istarget "*-*-elf*"] } {
 	return 0
     }
-    if { [istarget "arm*-*-*"]
-	 || [istarget "msp430-*-*"]
+    if { [istarget "msp430-*-*"]
 	 || [istarget "hppa-unknown-elf"]
 	 || [istarget "kvx*-*-*"]
 	 || [istarget "visium-*-*"] } {