[PATCH v3 17/18] PR ld/24600: BFD: Add general linker support for fake archives

[Maciej W. Rozycki]

On Tue, 9 Dec 2025, Jan Beulich wrote:

> > --- binutils-gdb.orig/bfd/opncls.c
> > +++ binutils-gdb/bfd/opncls.c
> > @@ -496,6 +496,47 @@ bfd_openstreamr (const char *filename, c
> >  
> >  /*
> >  FUNCTION
> > +	bfd_openr_fake_archive
> > +
> > +SYNOPSIS
> > +	bfd *bfd_openr_fake_archive (bfd *fbfd);
> > +
> > +DESCRIPTION
> > +	Open a list of BFDs starting from @var{filename} as an artificial
> 
> Elsewhere in this file @var{...} refers to function parameters; there is ...
> 
> > +	archive.  Subsequent members of the archive are indicated by each
> > +	BFD's proxy_handle.abfd member, with the final one holding a NULL
> > +	pointer there.  The newly opened archive will necessarily also be
> > +	a thin archive as there will be member files only to refer to and
> > +	no containing archive file.
> > +*/
> > +
> > +bfd *
> > +bfd_openr_fake_archive (bfd *fbfd)
> 
> ... no such function parameter here, though.

 Fixed in v4 with s/filename/fbfd/.

> Overall I feel like the underlying idea of "file collections" (plus why /
> where / when it's useful) isn't explained sufficiently in the description.
> Maybe that would become more clear by reading the next patch, but I think
> the patch here would best be self-contained.

 I'm not sure what else can be added here.  The change heading already 
mentions that this is for the linker (I've now added "linker" for clarity 
in a reference to symbol resolution in the first sentence as well) and the 
description overall says that a collection of files supplied via a call to 
`bfd_openr_fake_archive' will be treated by the BFD linker as if they were 
archive members.

 It then goes on to explain some implementation details.

 If you find anything particularly unclear, then please point me there.

  Maciej