public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: JunMa <JunMa@linux.alibaba.com>
To: gcc@gcc.gnu.org, binutils@sourceware.org
Subject: [RFC] gcc lto&binutils: Load different gcc's bfd-plugin automatically
Date: Tue, 05 Mar 2019 09:41:00 -0000	[thread overview]
Message-ID: <be65ea94-3469-0b6f-bdf8-ca0ac80b1b4b@linux.alibaba.com> (raw)

Hi All

We are now optimizing some projects with lto enabled, however,
there are some issues.
First, lto_plugin.so needs to be passed to ar/nm/ranlib.
For example, build static library with lto:

gcc -flto -O2 a.c -c -o a.o
gcc -flto -O2 b.c -c -o b.o
ar rcs --plugin=/path/to/lto_plugin.so   libx.a  a.o b.o

This is a little bit anoying. Also, it is not easy and convincible to use
gcc-ar/gcc-nm/gcc-ranlib on those projects. Luckily, binutils offers a
default plugin searching path(/lib/bfd-plugins), it can load plugin
automatically from that directory.

However, this brings up the second issue: binutils doesn't support multiple
version plugins of gccs which have the same plugin name:"lto_plugin.so"
int the same directory. Since these projects require different versions of
gccs, multiple gccs co-exist in our build system, we cannot put lto_plugin
in /lib/bfd-plugins. Although plugins may be compatible with each other,
we do want to decouple it among different versions of GCC.

I also have seen some discussions in
https://bugzilla.redhat.com/show_bug.cgi?id=1467409
where I don't seeany clear solutions.

I thought about this and had some ideas. I want ask for some feedback here.
The idea is to use versioned plugin searching paths
(/lib/bfd-plugins/$cc/$target/$version)
The $cc and $version information can be found in .comment section
of elf  file, as for file which does not have comment section, just keep
original searching path(/lib/bfd-plugins).

Here are few steps:
1) ar/nm/ranlib keep same behavior when '--plugin' is passed.
2) If --plugin is missed, find whether there are at least one .comment
section in object file/archive file if not goto 5).
3) for elf object file, get $cc and $version information. for elf 
archive file,
iterate comment section of all object files in archive, make sure $cc and
$version are same. if not, goto 5).
4) Get $target from target_alias variable in configure.
5) Find plugin from /lib/bfd-plugins/$cc/$target/$version or
/lib/bfd-plugins directory.

Looking forward to your replies!

Regards
Jun

             reply	other threads:[~2019-03-05  9:41 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-05  9:41 JunMa [this message]
2019-03-05  9:55 ` Richard Biener
2019-03-05 11:10   ` JunMa
2019-03-05 17:08   ` Joseph Myers

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=be65ea94-3469-0b6f-bdf8-ca0ac80b1b4b@linux.alibaba.com \
    --to=junma@linux.alibaba.com \
    --cc=binutils@sourceware.org \
    --cc=gcc@gcc.gnu.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).