All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicholas Piggin <npiggin@gmail.com>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>,
	Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
	Michal Marek <michal.lkml@markovi.net>
Subject: Re: [PATCH 1/2] kbuild: remove incremental linking option
Date: Mon, 19 Feb 2018 02:53:18 +1000	[thread overview]
Message-ID: <20180219025318.15e9fa17@roar.ozlabs.ibm.com> (raw)
In-Reply-To: <20180218142617.GA27096@ravnborg.org>

On Sun, 18 Feb 2018 15:26:17 +0100
Sam Ravnborg <sam@ravnborg.org> wrote:

> Hi Masahiro/Nicholas.
> 
> On Sun, Feb 11, 2018 at 03:04:08PM +0900, Masahiro Yamada wrote:
> > (+CC Sam)
> > 
> > 2018-02-10 23:25 GMT+09:00 Nicholas Piggin <npiggin@gmail.com>:  
> > > This removes the old `ld -r` incremental link option, which has not
> > > been selected by any architecture since June 2017.
> > >
> > > Signed-off-by: Nicholas Piggin <npiggin@gmail.com>  
> > 
> > 
> > Thanks for the last piece work!
> > 
> > BTW, as a loosely related topic,
> > I guess the following partial section analysis is not working any more.
> > 
> > # Do section mismatch analysis for each module/built-in.a
> > ifdef CONFIG_DEBUG_SECTION_MISMATCH
> >   cmd_secanalysis = ; scripts/mod/modpost $@
> > endif
> > 
> > 
> > 
> > If we use thin archive for built-in.o,
> > this is not ELF, so it is always skipped
> > by the following code.
> > 
> > 
> > if ((hdr->e_ident[EI_MAG0] != ELFMAG0) ||
> >     (hdr->e_ident[EI_MAG1] != ELFMAG1) ||
> >     (hdr->e_ident[EI_MAG2] != ELFMAG2) ||
> >     (hdr->e_ident[EI_MAG3] != ELFMAG3)) {
> >         /* Not an ELF file - silently ignore it */
> >         return 0;
> > 
> > 
> > The final analysis is done against vmlinux.o, which is ELF.
> > 
> > 
> > 
> > Is it better to remove CONFIG_DEBUG_SECTION_MISMATCH?
> > Or, do you have an idea to fix it?
> > 
> > 
> > I CCed Sam, the author of commit 91341d4.  
> 
> The section mismatch analysis for the individual built-in.o files
> was added to get warnings on a level close to where the source
> of the error was.
> So the warnings was more precise (the .o file gave a good hint
> where to look for the error).
> 
> 
> And since this has not been missed we should not try to add
> extra logic to re-introduce the check on this level.
> It would require an extra link for each directory only for
> the purpose of the section mismatch detection with
> better warnings.
> So we can safely get rid of this part.

This would be good. Perhaps now that the section mismatch analysis
has stamped out most such bugs, it is less trouble to work from
the final link analysis when they do appear.

> We still do an extra link of vmlinux to support section
> mismatch analysis.
> I wonder if we could do something to avoid this extra
> link step now where we use thin archieves unconditional.
> I assume this extra link step is more RAM and CPU consuming
> now than before thin archieves since it has to process
> many more .o files.
> So there should be some wins in build time if we
> can drop any extra step.

For the final link it's not too bad. The final built-in archive
that is created in the root directory contains symbol table and a
symbol index which the linker seems to process very quickly. I
found the difference is very small between thin and incremental.

It would be really nice in general to reduce the number of final
link passes though. We currently link it 4 times!

Thanks,
Nick

  reply	other threads:[~2018-02-18 16:53 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-10 14:25 [PATCH 0/2] remove the last of incremental linking Nicholas Piggin
2018-02-10 14:25 ` [PATCH 1/2] kbuild: remove incremental linking option Nicholas Piggin
2018-02-11  6:04   ` Masahiro Yamada
2018-02-18 14:26     ` Sam Ravnborg
2018-02-18 16:53       ` Nicholas Piggin [this message]
2018-02-10 14:25 ` [PATCH 2/2] kbuild: rename built-in.o to built-in.a Nicholas Piggin
2018-02-11  4:38   ` Masahiro Yamada
2018-02-11 11:15     ` Nicholas Piggin
2018-02-12  0:57       ` Masahiro Yamada
2018-02-12  1:26         ` Nicolas Pitre
2018-02-12  3:00           ` Masahiro Yamada
2018-02-12  3:08             ` Masahiro Yamada
2018-02-18 17:10   ` Sam Ravnborg
2018-02-19  7:04     ` Nicholas Piggin
2018-02-18 23:42 ` [PATCH 0/2] remove the last of incremental linking Masahiro Yamada

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180219025318.15e9fa17@roar.ozlabs.ibm.com \
    --to=npiggin@gmail.com \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=michal.lkml@markovi.net \
    --cc=sam@ravnborg.org \
    --cc=yamada.masahiro@socionext.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.