This is the mail archive of the
mailing list for the binutils project.
Re: [RFC] gcc lto&binutils: Load different gcc's bfd-plugin automatically
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: JunMa <JunMa at linux dot alibaba dot com>
- Cc: GCC Development <gcc at gcc dot gnu dot org>, Binutils <binutils at sourceware dot org>
- Date: Tue, 5 Mar 2019 10:55:26 +0100
- Subject: Re: [RFC] gcc lto&binutils: Load different gcc's bfd-plugin automatically
- References: <email@example.com>
On Tue, Mar 5, 2019 at 10:41 AM JunMa <JunMa@linux.alibaba.com> wrote:
> 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
> 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
> 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).
Well, why not go a step further and add a bfd-plugin note that suggests
the plugin to be used if it is installed? That could contain for example
lto_plugin_gcc8.so (to be installed in /lib/bfd-plugins/). Alternatively
a full path could be specified (though the files wouldn't then necessarily
work when moving between different compiler installs).
The install location could be modified to a location BFD searches just
for this note/comment but not for other auto-loading tries.
Or, since mostly archive related stuff is the issue, we could bundle
the plugin as a special archieve member... (ok, that creates a chicken
and egg issue at archieve creation time).
> 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!