Subject: Re: [PATCH 1/5] kbuild: allow architectures to use thin archives instead of ld -r

From: Sam Ravnborg <[email-masked]>
Date: Mon, 8 Aug 2016 06:46:27 +0200

On Mon, Aug 08, 2016 at 01:19:41PM +1000, Nicholas Piggin wrote:
> On Sun, 7 Aug 2016 16:40:54 +0200
> Sam Ravnborg <[email-masked]> wrote:
> 
> > On Sun, Aug 07, 2016 at 11:49:46AM +1000, Stephen Rothwell wrote:
> > > Hi Sam,
> > > 
> > > On Sat, 6 Aug 2016 22:10:45 +0200 Sam Ravnborg <[email-masked]> wrote:  
> > > >
> > > > Did you by any chance evalue the use of INPUT in linker files.
> > > > Stephen back then (again based on proposal from Alan Modra),
> > > > also made an implementation using INPUT.  
> > > 
> > > The problem with that idea was that (at least for some versions of
> > > binutils in use at the time) we hit a static limit to the number of
> > > object files and ld just stopped at that point. :-(  
> > 
> > The ld bug was caused by opening too many linked definitions files.
> > We can workaround this by expanding the files.
> > I gave this a quick spin - see below.
> > 
> > Note - I have no idea if using thin archived or this method is better.
> > But it seems just wrong to me that we convert to thin archives when
> > we really do not need to do so.
> > 
> > Note - this was a quick spin. It build fine here and thats it.
> 
> Is there a reason to prefer using linker scripts rather than thin
> archives? I thought the former was possibly a bit less robust, and
> the latter a smaller change for scripts and toolchain in terms
> of "almost behaving like an object file".

The only valid reason I can come up with is that it is simpler
to build a list of .o files than it is to generate a number
of thin archives.

I persuaded "linker scripts" mainly because I had the patch floating
and I was triggered by the powerpc discussions to resurface it again.

> I don't have a strong preference although do have a couple of
> (out of tree) scripts that expect objdump to work on built-in.o

You are likely not alone here.
Unless someone else comes up with any good reason lets stay with
thin archives.

	Sam