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

[Hans-Peter Nilsson]

> Date: Mon, 29 Sep 2025 17:26:28 +0100 (BST)
> From: "Maciej W. Rozycki" <macro@redhat.com>

> 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

Yeah, I read that part somewhat sloppily.

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

Of course, but isn't xfailing (or kfailing) for CRIS simple
and obvious?

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

That'd happen for xfail as well, AFAIK...

The only extant uses of kfail in the ld testsuite seem for
be in testsuite/ld-mips-elf/mips-elf.exp for some reason. ;)
So if we get to that point, I insist to use xfail, as is used
everywhere else in the ld testsuite.

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

[...]

Thanks for that, I'll look into this.

Bottom line: if your patch is approved in general before
I've made steps to fix that cris-aout-before-cris-elf wart,
please xfail the failing cases for cris*-elf and
cris*-linux.

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

Always happy to help with a bit of quirkiness.

Jokes aside, I agree, but now that we know about the issue,
it's no longer required for CRIS to point it out with what
appears to be a wart.

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

Right.

brgds, H-P