This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[PATCH 2/2] LD/testsuite: Expand STB_GNU_UNIQUE test coverage

Expand LD STB_GNU_UNIQUE testing across all eligible targets, as per the 
selection made in GAS, that is ones setting the OSABI to ELFOSABI_NONE 

	* testsuite/ld-unique/unique.exp: Run across all ELFOSABI_NONE 
	and ELFOSABI_GNU targets

 At first I thought this would be a good idea, prompting architecture 
maintainers to fix their code.  It wouldn't be over 5 years from commit 
f64b2e8d60f2 for me to notice there was something wrong with the MIPS 
target if we had any test suite failure for this feature (and then only 
because the IFUNC feature currently under review touches related code).

 But then I realised there's probably something wrong in the first place 
that we require maintainers' intervention for LD whereas we handle this 
stuff automagically across all the eligible targets in GAS (see obj-elf.c 
and `obj_elf_type' there).

 There was an observation made in the original review process here: 
<> that we should 
be limiting targets by the OSABI, but:

1. GAS does that already in generic code.

2. BFD per-target code doesn't do it anyway.

3. The choice whether to check the OSABI or not is independent from the 
   choice whether to handle this feature in generic or target-specific BFD 

So does anybody actually know why the current per-architecture approach 
was accepted in the review?

 If not then I'll post a proposal separately to gather all the bits 
scattered across target `*_add_symbol_hook' handlers and handle this 
feature in `elf_link_add_object_symbols'.

 Regardless, OK to apply this test suite change itself?


Index: binutils/ld/testsuite/ld-unique/unique.exp
--- binutils.orig/ld/testsuite/ld-unique/unique.exp	2016-04-30 06:35:48.586138927 +0100
+++ binutils/ld/testsuite/ld-unique/unique.exp	2016-04-30 17:10:41.934056441 +0100
@@ -24,20 +24,20 @@
 # Adapted for unique checking by Mark J. Wielaard <>
-# STB_GNU_UNIQUE support has only been implemented for the ix86, x86_64,
-# arm, mips, powerpc, and sparc so far.
-if {!(([istarget "i?86-*-*"]
-       || [istarget "x86_64-*-*"]
-       || [istarget "arm*-*-*"]
-       || [istarget "mips*-*-*"]
-       || [istarget "powerpc*-*-*"]
-       || [istarget "sparc*-*-*"])
-      && ([istarget "*-*-elf*"]
-	  || [istarget "*-*-nacl*"]
-	  || (([istarget "*-*-linux*"]
-	       || [istarget "*-*-gnu*"])
-	      && ![istarget "*-*-*aout*"]
-	      && ![istarget "*-*-*oldld*"]))) } {
+# Exclude non-ELF targets.
+if { ![is_elf_format] } {
+    return
+# Exclude some more targets; feel free to include your favorite one
+# if you like.  The MSP430 and Visium targets set the ELF header's
+# OSABI field to ELFOSABI_STANDALONE and cannot support STB_GNU_UNIQUE.
+if { !([istarget "*-*-elf*"]
+       && ![istarget "msp430-*-*"]
+       && ![istarget "visium-*-*"])
+     && ![istarget *-*-nacl*]
+     && ![istarget *-*-linux*]
+     && ![istarget *-*-gnu*] } {
     verbose "UNIQUE tests not run - target does not support UNIQUE"

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]