* [RFC] gcc lto&binutils: Load different gcc's bfd-plugin automatically
@ 2019-03-05 9:41 JunMa
2019-03-05 9:55 ` Richard Biener
0 siblings, 1 reply; 4+ messages in thread
From: JunMa @ 2019-03-05 9:41 UTC (permalink / raw)
To: gcc, binutils
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [RFC] gcc lto&binutils: Load different gcc's bfd-plugin automatically
2019-03-05 9:41 [RFC] gcc lto&binutils: Load different gcc's bfd-plugin automatically JunMa
@ 2019-03-05 9:55 ` Richard Biener
2019-03-05 11:10 ` JunMa
2019-03-05 17:08 ` Joseph Myers
0 siblings, 2 replies; 4+ messages in thread
From: Richard Biener @ 2019-03-05 9:55 UTC (permalink / raw)
To: JunMa; +Cc: GCC Development, Binutils
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
> 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).
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).
Richard.
> 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [RFC] gcc lto&binutils: Load different gcc's bfd-plugin automatically
2019-03-05 9:55 ` Richard Biener
@ 2019-03-05 11:10 ` JunMa
2019-03-05 17:08 ` Joseph Myers
1 sibling, 0 replies; 4+ messages in thread
From: JunMa @ 2019-03-05 11:10 UTC (permalink / raw)
To: Richard Biener; +Cc: GCC Development, Binutils
å¨ 2019/3/5 ä¸å5:55, Richard Biener åé:
> 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
>> 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).
> 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).
Well, I also thought about add new section to contain lto_plugin info,
however,
in order to parse lto related sections in binutils, you need load lto_plugin
first. I'm not sure whether this idea can be accepted.(it's sort of another
chicken and egg issue).
> The install location could be modified to a location BFD searches just
> for this note/comment but not for other auto-loading tries.
Of course, I prefer this general idea than only support elf.
> 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).
>
> Richard.
>> 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
Regards
Jun
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [RFC] gcc lto&binutils: Load different gcc's bfd-plugin automatically
2019-03-05 9:55 ` Richard Biener
2019-03-05 11:10 ` JunMa
@ 2019-03-05 17:08 ` Joseph Myers
1 sibling, 0 replies; 4+ messages in thread
From: Joseph Myers @ 2019-03-05 17:08 UTC (permalink / raw)
To: Richard Biener; +Cc: JunMa, GCC Development, Binutils
On Tue, 5 Mar 2019, Richard Biener wrote:
> 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).
I think specifying full paths to code to execute in object files if very
dubious on security grounds.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-03-05 17:08 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-03-05 9:41 [RFC] gcc lto&binutils: Load different gcc's bfd-plugin automatically JunMa
2019-03-05 9:55 ` Richard Biener
2019-03-05 11:10 ` JunMa
2019-03-05 17:08 ` Joseph Myers
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).