[PATCH 7/8] PR ld/24600: BFD: Add general linker support for mapless archives

[Maciej W. Rozycki]

On Sat, 27 Sep 2025, Hans-Peter Nilsson wrote:

> > This, notably, has triggered test failures:
> > 
> > cris-elf  +FAIL: Regular archive w/o index link
> > cris-elf  +FAIL: Thin archive w/o index link
> > crisv32-linux  +FAIL: Regular archive w/o index link
> > crisv32-linux  +FAIL: Thin archive w/o index link
> > 
> > all caused by a segfault in `aout_get_external_symbols' trying to access 
> > `aout_data' data of an ELF BFD.
> > 
> > This comes from a combination of factors.  Firstly, ELF and Linux CRIS 
> > targets set the default BFD target to a.out and at the same time they 
> > set the default linker emulation to ELF.  Secondly, for mapless archives 
> > code in `bfd_check_format_matches' ignores the BFD target supplied by 
> > the linker and resorts to iterating over all the BFD formats to find one 
> > to match.  Thirdly, when called in the linker `bfd_generic_archive_p' 
> > accepts any archive file without any verification of its member files.  
> > Consequently the default a.out BFD target is chosen for ELF input.
> > 
> > This only affects the new feature and is not a regression, so shouldn't 
> > stop this change and will best be sorted independently.
> 
> I can read the above as you're suggesting this patch,
> despite it causing a regression in test results for cris-elf
> and crisv32-linux, and still say it is "not a regression"?
> 
> I hope I misunderstood.  Perhaps those are new tests ("git
> grep" doesn't hit).  Then please xfail them for cris*-elf
> and cris*-linux.  I don't think we use kfail, that seems
> more gdb?

 Definitely not a regression: the tests are new and the feature they cover 
is new as well.  It's just that the feature as it stands is not going to 
work for CRIS, and FAOD I'm not happy about it at all.

 The issue however is in generic archive handling code and it's not clear 
to me what the proper way to move forward is for BFD here.  I'm happy to 
discuss solutions, but I'd rather that didn't hold the feature, which is 
tangential to the issue triggered.

 Also I'm in favour of using KFAIL where applicable according to DejaGNU 
test result interpretation guidelines as it allows for a PR to be named 
and visible in the test log, so that a KPASS lets one know right away 
where to look.

> I'm open to other changes that don't cause testsuite
> regressions, like to the effect of not defaulting to a.out.

 A change such as:

diff --git a/bfd/config.bfd b/bfd/config.bfd
index 9fa1c51a9a2..a51fd9d51dd 100644
--- a/bfd/config.bfd
+++ b/bfd/config.bfd
@@ -455,7 +455,7 @@ case "${targ}" in
     targ_underscore=yes
     ;;
 
-  cris-*-* | crisv32-*-*)
+  cris-*-*aout*)
     targ_defvec=cris_aout_vec
     targ_selvecs="cris_elf32_us_vec cris_elf32_vec"
     case "${targ}" in
@@ -465,6 +465,18 @@ case "${targ}" in
     want64=true
     ;;
 
+  cris-*-linux-* | crisv32-*-linux-*)
+    targ_defvec=cris_elf32_vec
+    want64=true
+    ;;
+
+  cris-*-* | crisv32-*-*)
+    targ_defvec=cris_elf32_us_vec
+    targ_selvecs="cris_aout_vec cris_elf32_vec"
+    targ_underscore=yes
+    want64=true
+    ;;
+
   crx-*-elf*)
     targ_defvec=crx_elf32_vec
     targ_underscore=yes

would match ld/configure.tgt AFAICT; I haven't verified this patch in any 
way though.

> I don't remember that one, but it sounds wrong.

 Well, whether you want to update CRIS is up to you really.  But I think 
we ought to address the issues in generic archive handling regardless, and 
in a way I'm glad for this odd arrangement for CRIS to have uncovered the 
matter.  In particular with numerous target configurations you can request 
a non-default emulation for LD to work with, which then won't match the 
default BFD target, and such an invocation of LD ought to still get the 
handling of archives right.

  Maciej