[PATCH 1/5] kbuild: allow architectures to use thin archives instead of ld -r
Sam Ravnborg
sam at ravnborg.org
Mon Aug 8 14:46:27 AEST 2016
On Mon, Aug 08, 2016 at 01:19:41PM +1000, Nicholas Piggin wrote:
> On Sun, 7 Aug 2016 16:40:54 +0200
> Sam Ravnborg <sam at ravnborg.org> 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 <sam at ravnborg.org> 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
More information about the Linuxppc-dev
mailing list