This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH][RFH] Add dg-requires-linker-plugin support


On Wed, Jul 21, 2010 at 9:32 PM, Ralf Wildenhues <Ralf.Wildenhues@gmx.de> wrote:
> Hello,
>
> * Richard Guenther wrote on Wed, Jul 21, 2010 at 08:48:52PM CEST:
>> > This adds a check for working linker-plugin support to the
>> > testsuite. ?It's includes a hack to add a -B to find the lto plugin
>> > in a built tree (Janis, is there some variable available that
>> > specifies the root of the build tree? ?For installed testing not
>> > specifying the -B should be ok). ?Should/can the
>> > dg-require-linker-plugin automatically add to ld-additional-options
>> > (still allowing that to append others?).
>> >
>> > Thus, not "ok?", but - any help here?
>> >
>> > It works in a built tree with linker plugin support and it properly
>> > makes the test unsupported if I mess up the -B argument (thus it
>> > should also work in a tree w/o linker plugin support).
>>
>> Another way would be to copy lto-plugin.so to gcc/, similar to how we
>> do for libgcc_s.so. ?But I am quite lost on how to do that with the current
>> lto-plugin makefiles (not to mention the dependency issue if we want to
>> make use of this during LTO bootstrap as well).
>>
>> Ralf - do you have an idea where to hook the copying with automake?
>
> I don't yet understand from the above description, what depends on what,
> and at what time do you need what to be done? ?In an LTO bootstrap, when
> is lto-plugin needed, and by who?
>
> I can give some general hints, but I guess that won't help you too much:
> if you need to have some action be done before the usual targets built
> by "make all", then list them in BUILT_SOURCES; to add generic targets
> to be built sometime during "make all", just make them prerequisites of
> the "all-local" target.
>
> The early copyback of libgcc is done within libgcc/Makefile (search for
> "Early copyback"). ?The part missing in lto-plugin is the extension of
> the shared object and $(LT_OBJDIR). ?I assume GCC already has a variable
> for the former? ?Otherwise, you can set module=yes and eval $shrext_cmds
> after AC_PROG_LIBTOOL; that won't give you the right name on all systems
> yet but I think on all which LTO currently supports.
>
> The other thing that probably needs adjusting is toplevel Makefile.defs
> dependencies line so that *all-lto-plugin is run before anything that
> needs it.
>
> I haven't been looking at GCC for a little while now, sorry.

Ok, I think I have found my way through it and came up with the
following simple solution that works for me (the testsuite changes
work and for LTO bootstrap adding -B /../prev-lto-plugin/.libs to
BOOT_CFLAGS is no longer necessary.

Thus - ok for mainline?

Thanks,
Richard.

2010-07-22  Richard Guenther  <rguenther@suse.de>

        lto-plugin/
        * Makefile.am: New copy_lto_plugin rule to install the plugin
        into ../gcc.
        * Makefile.in: Regenerated.

Attachment: p3
Description: Binary data


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]