Patchwork Add -print-lto-plugin

login
register
mail settings
Submitter Andi Kleen
Date Oct. 2, 2010, 9:24 p.m.
Message ID <1286054674-20295-1-git-send-email-andi@firstfloor.org>
Download mbox | patch
Permalink /patch/66586/
State New
Headers show

Comments

Andi Kleen - Oct. 2, 2010, 9:24 p.m.
From: Andi Kleen <ak@linux.intel.com>

binutils have LTO linker plugin support now, but it requires hardcoding
the path to gcc's libexec dir in the Makefile. Add an option to the
gcc driver instead to print the full file name to avoid this.

This is especially useful for ar or nm.

Passes bootstrap and test on x86-64.

Ok to commit?

2010-10-02  Andi Kleen <ak@linux.intel.com>

	* common.opt (-print-lto-plugin): Add.
	* doc/invoke.texi (-print-lto-plugin): Document.
	* gcc.c (display_help): Describe -print-lto-plugin.
	(main.c): Handle print_lto_plugin.
---
 gcc/common.opt      |    6 ++++++
 gcc/doc/invoke.texi |    9 ++++++++-
 gcc/gcc.c           |   13 +++++++++++++
 3 files changed, 27 insertions(+), 1 deletions(-)
H.J. Lu - Oct. 3, 2010, 3:41 a.m.
On Sat, Oct 2, 2010 at 2:24 PM, Andi Kleen <andi@firstfloor.org> wrote:
> From: Andi Kleen <ak@linux.intel.com>
>
> binutils have LTO linker plugin support now, but it requires hardcoding
> the path to gcc's libexec dir in the Makefile. Add an option to the
> gcc driver instead to print the full file name to avoid this.
>


It sounds wrong to me. Linker shouldn't hardcode the path to
gcc's libexec, which should be passed down to linker from gcc.
H.J. Lu - Oct. 3, 2010, 7:18 a.m.
On Sat, Oct 2, 2010 at 8:41 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Sat, Oct 2, 2010 at 2:24 PM, Andi Kleen <andi@firstfloor.org> wrote:
>> From: Andi Kleen <ak@linux.intel.com>
>>
>> binutils have LTO linker plugin support now, but it requires hardcoding
>> the path to gcc's libexec dir in the Makefile. Add an option to the
>> gcc driver instead to print the full file name to avoid this.
>>
>
>
> It sounds wrong to me. Linker shouldn't hardcode the path to
> gcc's libexec, which should be passed down to linker from gcc.
>

If you are referring to "ar --plugin", gcc-ar or something like it
works better.
Andi Kleen - Oct. 3, 2010, 9:36 a.m.
"H.J. Lu" <hjl.tools@gmail.com> writes:

> On Sat, Oct 2, 2010 at 8:41 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Sat, Oct 2, 2010 at 2:24 PM, Andi Kleen <andi@firstfloor.org> wrote:
>>> From: Andi Kleen <ak@linux.intel.com>
>>>
>>> binutils have LTO linker plugin support now, but it requires hardcoding
>>> the path to gcc's libexec dir in the Makefile. Add an option to the
>>> gcc driver instead to print the full file name to avoid this.
>>>
>>
>>
>> It sounds wrong to me. Linker shouldn't hardcode the path to
>> gcc's libexec, which should be passed down to linker from gcc.
>
> If you are referring to "ar --plugin", gcc-ar or something like it
> works better.

ar, ranlib and nm yes.

Are you suggesting to add standard gcc-ar / gcc-ranlib 
wrappers to gcc?

If that's the consensus I can do that, but personally
ar --plugin `gcc -print-lto-plugin`  seems better for me.

[That is there is still a bug in binutils that you
always have to set GNUTARGET=plugin too, but I hope that
will get eventually fixed]

The advantage of the option that it dynamically adapts to different CCs
passed into Makefiles. With the separate wrapper I would always need to
pass a special ar and ranlib too for different compiler versions. I do
that today and it's somewhat annoying to type.

And another advantage is that it doesn't mess with command line
completion for "gcc".

-Andi
H.J. Lu - Oct. 3, 2010, 9:43 a.m.
On Sun, Oct 3, 2010 at 2:36 AM, Andi Kleen <andi@firstfloor.org> wrote:
> "H.J. Lu" <hjl.tools@gmail.com> writes:
>
>> On Sat, Oct 2, 2010 at 8:41 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>> On Sat, Oct 2, 2010 at 2:24 PM, Andi Kleen <andi@firstfloor.org> wrote:
>>>> From: Andi Kleen <ak@linux.intel.com>
>>>>
>>>> binutils have LTO linker plugin support now, but it requires hardcoding
>>>> the path to gcc's libexec dir in the Makefile. Add an option to the
>>>> gcc driver instead to print the full file name to avoid this.
>>>>
>>>
>>>
>>> It sounds wrong to me. Linker shouldn't hardcode the path to
>>> gcc's libexec, which should be passed down to linker from gcc.
>>
>> If you are referring to "ar --plugin", gcc-ar or something like it
>> works better.
>
> ar, ranlib and nm yes.
>
> Are you suggesting to add standard gcc-ar / gcc-ranlib
> wrappers to gcc?
>
> If that's the consensus I can do that, but personally
> ar --plugin `gcc -print-lto-plugin`  seems better for me.

You can use

gcc -print-prog-name=liblto_plugin.so

today.

> [That is there is still a bug in binutils that you
> always have to set GNUTARGET=plugin too, but I hope that
> will get eventually fixed]

It has been fixed. If not, please open a bug report.
Andi Kleen - Oct. 3, 2010, 10:01 a.m.
On Sun, Oct 03, 2010 at 02:43:33AM -0700, H.J. Lu wrote:
> You can use
> 
> gcc -print-prog-name=liblto_plugin.so
> 
> today.

That is true, but it looks much uglier than the simple option.
Also I'm not sure it's a good idea to hardcode the lto plugin
name in Makefiles.

So I would prefer to still have the higher-level option.

> 
> > [That is there is still a bug in binutils that you
> > always have to set GNUTARGET=plugin too, but I hope that
> > will get eventually fixed]
> 
> It has been fixed. If not, please open a bug report.

Still broken on binutils master as today. I filed a bug:
http://sourceware.org/bugzilla/show_bug.cgi?id=12088

-Andi
Andi Kleen - Oct. 3, 2010, 10:05 a.m.
Good point that the option makes sense on non Unix.

>   So I'd be in favour of adding this option, but not in it's current shape:
> I'd like the code behind it to determine shared lib prefix and suffix
> correctly for the platform.

The new code uses the exact same method as the rest of gcc.c, which
hard codes the file name.

If you add some other method presumably my code could be converted
at the same time.

But I don't think it makes sense to delay it for something that
doesn't exist today.

-Andi
Dave Korn - Oct. 3, 2010, 10:09 a.m.
On 03/10/2010 10:43, H.J. Lu wrote:
> On Sun, Oct 3, 2010 at 2:36 AM, Andi Kleen <andi@firstfloor.org> wrote:
>> "H.J. Lu" <hjl.tools@gmail.com> writes:
>>
>>> On Sat, Oct 2, 2010 at 8:41 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>> On Sat, Oct 2, 2010 at 2:24 PM, Andi Kleen <andi@firstfloor.org> wrote:
>>>>> From: Andi Kleen <ak@linux.intel.com>
>>>>>
>>>>> binutils have LTO linker plugin support now, but it requires hardcoding
>>>>> the path to gcc's libexec dir in the Makefile. Add an option to the
>>>>> gcc driver instead to print the full file name to avoid this.
>>>>>
>>>>
>>>> It sounds wrong to me. Linker shouldn't hardcode the path to
>>>> gcc's libexec, which should be passed down to linker from gcc.
>>> If you are referring to "ar --plugin", gcc-ar or something like it
>>> works better.
>> ar, ranlib and nm yes.
>>
>> Are you suggesting to add standard gcc-ar / gcc-ranlib
>> wrappers to gcc?
>>
>> If that's the consensus I can do that, but personally
>> ar --plugin `gcc -print-lto-plugin`  seems better for me.
> 
> You can use
> 
> gcc -print-prog-name=liblto_plugin.so
> 
> today.

  That's true, and I would recommend not adding the patch as-is, since it's
just a redundant synonym at the moment.

  OTOH, on some targets the linker plugin isn't going to be called
"liblto_plugin.so" any more, and it would be good if we a) don't hard-code
that name any further in GCC's code, and b) provided a way for the user to
find it out from GCC.

  So I'd be in favour of adding this option, but not in it's current shape:
I'd like the code behind it to determine shared lib prefix and suffix
correctly for the platform.

    cheers,
      DaveK
Dave Korn - Oct. 3, 2010, 10:10 a.m.
On 03/10/2010 11:09, Dave Korn wrote:

>   OTOH, on some targets the linker plugin isn't going to be called

  Minor typo: should say hosts, not targets, of course.

    cheers,
      DaveK
H.J. Lu - Oct. 3, 2010, 11:01 a.m.
On Sun, Oct 3, 2010 at 3:01 AM, Andi Kleen <andi@firstfloor.org> wrote:
> On Sun, Oct 03, 2010 at 02:43:33AM -0700, H.J. Lu wrote:
>> You can use
>>
>> gcc -print-prog-name=liblto_plugin.so
>>
>> today.
>
> That is true, but it looks much uglier than the simple option.
> Also I'm not sure it's a good idea to hardcode the lto plugin
> name in Makefiles.
>
> So I would prefer to still have the higher-level option.
>

I prefer gcc provide a wrapper for ar and nm".  It is
much easier to use.  Imaging if you have to call linker
directly.
Dave Korn - Oct. 3, 2010, 11:02 a.m.
On 03/10/2010 11:05, Andi Kleen wrote:
> Good point that the option makes sense on non Unix.
> 
>>   So I'd be in favour of adding this option, but not in it's current shape:
>> I'd like the code behind it to determine shared lib prefix and suffix
>> correctly for the platform.
> 
> The new code uses the exact same method as the rest of gcc.c, which
> hard codes the file name.

  That's a *bad* thing, not a good one!

> If you add some other method presumably my code could be converted
> at the same time.

  I guess I just have an instinctive reaction against copy-pasting badness
into extra places than it already exists.  At least it's in the same C file so
I won't be all that likely to miss it.

> But I don't think it makes sense to delay it for something that
> doesn't exist today.

  Well, I see your point about not wanting to hardcode the plugin name into
makefiles.

    cheers,
      DaveK
Andi Kleen - Oct. 3, 2010, 11:07 a.m.
On Sun, Oct 03, 2010 at 04:01:19AM -0700, H.J. Lu wrote:
> On Sun, Oct 3, 2010 at 3:01 AM, Andi Kleen <andi@firstfloor.org> wrote:
> > On Sun, Oct 03, 2010 at 02:43:33AM -0700, H.J. Lu wrote:
> >> You can use
> >>
> >> gcc -print-prog-name=liblto_plugin.so
> >>
> >> today.
> >
> > That is true, but it looks much uglier than the simple option.
> > Also I'm not sure it's a good idea to hardcode the lto plugin
> > name in Makefiles.
> >
> > So I would prefer to still have the higher-level option.
> >
> 
> I prefer gcc provide a wrapper for ar and nm".  It is
> much easier to use.  Imaging if you have to call linker
> directly.

Perhaps both could be done? The option is a good way 
to implement the wrappers.

I can send a followon patch with suitable wrappers, but 
I'm not fully sure how to do the necessary autoconf magic
to detect the binutils support.

-Andi
H.J. Lu - Oct. 4, 2010, 12:28 p.m.
On Sun, Oct 3, 2010 at 4:07 AM, Andi Kleen <andi@firstfloor.org> wrote:
> On Sun, Oct 03, 2010 at 04:01:19AM -0700, H.J. Lu wrote:
>> On Sun, Oct 3, 2010 at 3:01 AM, Andi Kleen <andi@firstfloor.org> wrote:
>> > On Sun, Oct 03, 2010 at 02:43:33AM -0700, H.J. Lu wrote:
>> >> You can use
>> >>
>> >> gcc -print-prog-name=liblto_plugin.so
>> >>
>> >> today.
>> >
>> > That is true, but it looks much uglier than the simple option.
>> > Also I'm not sure it's a good idea to hardcode the lto plugin
>> > name in Makefiles.
>> >
>> > So I would prefer to still have the higher-level option.
>> >
>>
>> I prefer gcc provide a wrapper for ar and nm".  It is
>> much easier to use.  Imaging if you have to call linker
>> directly.
>
> Perhaps both could be done? The option is a good way
> to implement the wrappers.
>
> I can send a followon patch with suitable wrappers, but
> I'm not fully sure how to do the necessary autoconf magic
> to detect the binutils support.
>

Just for the record. GCC has everything we need to
create wrappers, like lto-ar/lto-nm.  Of cause, those
wrappers will be host/target dependent.  We can create those
wrappers at configure/build time today.
Andi Kleen - Oct. 4, 2010, 12:46 p.m.
> Just for the record. GCC has everything we need to
> create wrappers, like lto-ar/lto-nm.  Of cause, those
> wrappers will be host/target dependent.  We can create those
> wrappers at configure/build time today.

Can you explain that a bit more please?  What is "everything"?

-Andi

Patch

diff --git a/gcc/common.opt b/gcc/common.opt
index 44a3de8..fe8e718 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -157,6 +157,9 @@  Driver JoinedOrMissing Alias(print-file-name=)
 -print-libgcc-file-name
 Driver Alias(print-libgcc-file-name)
 
+-print-lto-plugin
+Driver Alias(print-lto-plugin)
+
 -print-multi-directory
 Driver Alias(print-multi-directory)
 
@@ -1902,6 +1905,9 @@  Driver JoinedOrMissing Var(print_file_name)
 print-libgcc-file-name
 Driver
 
+print-lto-plugin
+Driver Var(print_lto_plugin)
+
 print-multi-directory
 Driver Var(print_multi_directory)
 
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 057ae7d..530d4dc 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -322,7 +322,7 @@  Objective-C and Objective-C++ Dialects}.
 -fdebug-prefix-map=@var{old}=@var{new} @gol
 -femit-struct-debug-baseonly -femit-struct-debug-reduced @gol
 -femit-struct-debug-detailed@r{[}=@var{spec-list}@r{]} @gol
--p  -pg  -print-file-name=@var{library}  -print-libgcc-file-name @gol
+-p  -pg  -print-file-name=@var{library}  -print-libgcc-file-name  -print-lto-plugin @gol
 -print-multi-directory  -print-multi-lib  -print-multi-os-directory @gol
 -print-prog-name=@var{program}  -print-search-dirs  -Q @gol
 -print-sysroot -print-sysroot-headers-suffix @gol
@@ -5715,6 +5715,13 @@  Same as @option{-print-file-name=libgcc.a}.
 This is useful when you use @option{-nostdlib} or @option{-nodefaultlibs}
 but you do want to link with @file{libgcc.a}.  You can do
 
+@item -print-lto-plugin
+@opindex print-lto-plugin
+Print the path name of the LTO linker plugin used by the compiler.
+
+This is useful to pass to ar, gold, ld or other binutils with linker 
+plugin support. 
+
 @smallexample
 gcc -nostdlib @var{files}@dots{} `gcc -print-libgcc-file-name`
 @end smallexample
diff --git a/gcc/gcc.c b/gcc/gcc.c
index ef637e9..ea0987a 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -2937,6 +2937,7 @@  display_help (void)
   fputs (_("  -dumpmachine             Display the compiler's target processor\n"), stdout);
   fputs (_("  -print-search-dirs       Display the directories in the compiler's search path\n"), stdout);
   fputs (_("  -print-libgcc-file-name  Display the name of the compiler's companion library\n"), stdout);
+  fputs (_("  -print-lto-plugin        Display the name of the compiler's LTO plugin\n"), stdout);
   fputs (_("  -print-file-name=<lib>   Display the full path to library <lib>\n"), stdout);
   fputs (_("  -print-prog-name=<prog>  Display the full path to compiler component <prog>\n"), stdout);
   fputs (_("  -print-multi-directory   Display the root directory for versions of libgcc\n"), stdout);
@@ -3229,6 +3230,7 @@  driver_handle_option (struct gcc_options *opts,
     case OPT_print_sysroot:
     case OPT_print_multi_os_directory:
     case OPT_print_sysroot_headers_suffix:
+    case OPT_print_lto_plugin:
     case OPT_time:
     case OPT_wrapper:
       /* These options set the variables specified in common.opt
@@ -6534,6 +6536,17 @@  main (int argc, char **argv)
 	fatal_error ("not configured with sysroot headers suffix");
     }
 
+  if (print_lto_plugin)
+    {
+      char *plugin;
+
+      plugin = find_a_file (&exec_prefixes, "liblto_plugin.so", R_OK, false);
+      if (!plugin)
+        fatal_error ("-print-lto-plugin specified, but no plugin found");    
+      printf ("%s\n", plugin);
+      return (0);
+    }
+
   if (print_help_list)
     {
       display_help ();