| Message ID | 1286054674-20295-1-git-send-email-andi@firstfloor.org |
|---|---|
| State | New |
| Headers | show |
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.
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.
"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
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.
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
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
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
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
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.
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
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
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.
> 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
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 ();
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(-)