On Fri, Dec 3, 2010 at 6:15 PM, Ian Lance Taylor wrote:
> Dave Korn writes:
>
>> On 04/12/2010 01:24, H.J. Lu wrote:
>>
>>> I checked in a patch to implement stage 2 linking. Everything
>>> seems to work, including "gcc -static ... -lm".
>>
>> Any chance you could send a complete diff?
>
> I ju
On Fri, Dec 3, 2010 at 6:34 PM, H.J. Lu wrote:
> On Fri, Dec 3, 2010 at 6:23 PM, Dave Korn wrote:
>> On 04/12/2010 01:24, H.J. Lu wrote:
>>
>>> I checked in a patch to implement stage 2 linking. Everything
>>> seems to work, including "gcc -static ... -lm".
>>
>> Any chance you could send a comp
On Fri, Dec 3, 2010 at 6:23 PM, Dave Korn wrote:
> On 04/12/2010 01:24, H.J. Lu wrote:
>
>> I checked in a patch to implement stage 2 linking. Everything
>> seems to work, including "gcc -static ... -lm".
>
> Any chance you could send a complete diff?
>
I will submit a complete diff after I fix
Dave Korn writes:
> On 04/12/2010 01:24, H.J. Lu wrote:
>
>> I checked in a patch to implement stage 2 linking. Everything
>> seems to work, including "gcc -static ... -lm".
>
> Any chance you could send a complete diff?
I just want to note that I continue to think this is a really bad idea,
a
On 04/12/2010 01:24, H.J. Lu wrote:
> I checked in a patch to implement stage 2 linking. Everything
> seems to work, including "gcc -static ... -lm".
Any chance you could send a complete diff?
cheers,
DaveK
On Fri, Dec 3, 2010 at 4:49 PM, H.J. Lu wrote:
> On Fri, Dec 3, 2010 at 11:16 AM, H.J. Lu wrote:
>> On Fri, Dec 3, 2010 at 11:10 AM, Cary Coutant wrote:
>> Another way to do this would be to put a marker in the command line
>> that identifies where those libraries begin, and the linker c
On Fri, Dec 3, 2010 at 11:16 AM, H.J. Lu wrote:
> On Fri, Dec 3, 2010 at 11:10 AM, Cary Coutant wrote:
> Another way to do this would be to put a marker in the command line
> that identifies where those libraries begin, and the linker could just
> go back and rescan those libraries if
On Fri, Dec 3, 2010 at 11:10 AM, Cary Coutant wrote:
Another way to do this would be to put a marker in the command line
that identifies where those libraries begin, and the linker could just
go back and rescan those libraries if needed, before the final layout
of the endcaps.
>>> Another way to do this would be to put a marker in the command line
>>> that identifies where those libraries begin, and the linker could just
>>> go back and rescan those libraries if needed, before the final layout
>>> of the endcaps.
>>
>> I like that idea in general, but the difficulty is k
> For the crtend files we could add a linker option that makes them
> known as endcaps, and the linker could make sure they get laid out
> last:
>
> ld ... -lc -lgcc ... --endcap crtend.o crtn.o
>
> That puts the special knowledge about those files back in the gcc driver.
I should have remembere
Cary Coutant writes:
> My suggestion was to have the plugin give the linker a list of
> libcalls, and the linker would note where it found each symbol during
> its normal library scanning.
Ah, I see. OK, that makes sense.
> Right. The gcc driver would have to have some concept of which
> libra
>> I wouldn't expect the compiler to introduce a call to anything in libm
>> when -lm isn't already specified on the command line (that would break
>> even without LTO).
>
> Right--that would break without LTO, but it doesn't follow that we
> should make it work with LTO.
That's my point, too.
>>
On Thu, Dec 2, 2010 at 5:39 PM, Ian Lance Taylor wrote:
> Cary Coutant writes:
>
>>> This isn't quite what should happen, though. If the user does not
>>> specify -lm on the link line, then we should not add -lm, even if LTO
>>> somehow introduces a function that is defined in libm. Automatical
Cary Coutant writes:
>> This isn't quite what should happen, though. If the user does not
>> specify -lm on the link line, then we should not add -lm, even if LTO
>> somehow introduces a function that is defined in libm. Automatically
>> adding -lm would introduce a surprising dynamic dependenc
On Thu, Dec 2, 2010 at 4:04 PM, Cary Coutant wrote:
>> This isn't quite what should happen, though. If the user does not
>> specify -lm on the link line, then we should not add -lm, even if LTO
>> somehow introduces a function that is defined in libm. Automatically
>> adding -lm would introduce
> This isn't quite what should happen, though. If the user does not
> specify -lm on the link line, then we should not add -lm, even if LTO
> somehow introduces a function that is defined in libm. Automatically
> adding -lm would introduce a surprising dynamic dependency in some
> cases. The use
>> For the crtend files we could add a linker option that makes them
>> known as endcaps, and the linker could make sure they get laid out
>> last:
>>
>> ld ... -lc -lgcc ... --endcap crtend.o crtn.o
>>
>> That puts the special knowledge about those files back in the gcc driver.
>
> Hmm, yes.
Cary Coutant writes:
>> For each libcall, we need to decorate
>>
>> 1. Which library it comes from. It is OS/target dependent.
>> 2. The dynamic and static library names. In most cases, they
>> are the same. For glibc, they are different.
>
> Is there a relatively painless way to enumerate all
On 02/12/2010 23:29, Cary Coutant wrote:
> For the crtend files we could add a linker option that makes them
> known as endcaps, and the linker could make sure they get laid out
> last:
>
>ld ... -lc -lgcc ... --endcap crtend.o crtn.o
>
> That puts the special knowledge about those files bac
> For each libcall, we need to decorate
>
> 1. Which library it comes from. It is OS/target dependent.
> 2. The dynamic and static library names. In most cases, they
> are the same. For glibc, they are different.
Is there a relatively painless way to enumerate all the possible
libcalls? We coul
On Thu, Dec 2, 2010 at 1:10 PM, Cary Coutant wrote:
>
> For every new routine that the gcc backend generates a new call to, it
> ought to know which library that routine is defined in, and should be
> able to add that library after the generated object(s) during the
> all-symbols-read callback. We
On Thu, Dec 2, 2010 at 1:28 PM, H.J. Lu wrote:
>> For every new routine that the gcc backend generates a new call to, it
>> ought to know which library that routine is defined in, and should be
>> able to add that library after the generated object(s) during the
>> all-symbols-read callback. We re
Cary Coutant writes:
>> I propose that we add a new linker option: --plugin-callback. At each
>> point where this option appears on the command line, the linker will
>> call a new plugin callback entry point. The LTO plugin will replace the
>> all_symbols_read callback with this one. We will h
On Thu, Dec 2, 2010 at 1:10 PM, Cary Coutant wrote:
>> I propose that we add a new linker option: --plugin-callback. At each
>> point where this option appears on the command line, the linker will
>> call a new plugin callback entry point. The LTO plugin will replace the
>> all_symbols_read call
> I propose that we add a new linker option: --plugin-callback. At each
> point where this option appears on the command line, the linker will
> call a new plugin callback entry point. The LTO plugin will replace the
> all_symbols_read callback with this one. We will have the gcc driver
> run th
On Thu, Dec 2, 2010 at 1:01 PM, Cary Coutant wrote:
>> I'm wondering if the linker shouldn't just gather the plugin-contributed
>> object files, substitute them into appropriate places on the original
>> command-line, and re-exec itself.
>
> That's not effectively different from the collect2 appr
> I'm wondering if the linker shouldn't just gather the plugin-contributed
> object files, substitute them into appropriate places on the original
> command-line, and re-exec itself.
That's not effectively different from the collect2 approach that we
had before the linker plugin interface. The on
Dave Korn writes:
> On 02/12/2010 20:10, Ian Lance Taylor wrote:
>
>> Anyhow, I have a proposal on the table which I think can do the job. If
>> you want to instead advocate for a complete relink approach, then we
>> should significantly change and simplify the plugin interface. The
>> plugin s
On 02/12/2010 20:10, Ian Lance Taylor wrote:
> Anyhow, I have a proposal on the table which I think can do the job. If
> you want to instead advocate for a complete relink approach, then we
> should significantly change and simplify the plugin interface. The
> plugin support in gold will need to
On Thu, Dec 2, 2010 at 12:10 PM, Ian Lance Taylor wrote:
>
> Anyhow, I have a proposal on the table which I think can do the job. If
> you want to instead advocate for a complete relink approach, then we
> should significantly change and simplify the plugin interface. The
> plugin support in gol
"H.J. Lu" writes:
>> As far as I can tell at this point, the complete set of libraries we
>> need to check is: -lc -lm -lgcc -lgcc_s.
>
> It isn't a complete list. At least, we need -lgcov and may be others.
Only to the extent that we feel that it is important to permit the user
to specify -lgco
On Thu, Dec 2, 2010 at 11:53 AM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> On Thu, Dec 2, 2010 at 11:37 AM, Ian Lance Taylor wrote:
>>> "H.J. Lu" writes:
>>>
g++ adds -lm since libstdc++ uses libm. If we do it in gcc, we may
add run-time dependency on libm.so to all C programs
"H.J. Lu" writes:
> On Thu, Dec 2, 2010 at 11:37 AM, Ian Lance Taylor wrote:
>> "H.J. Lu" writes:
>>
>>> g++ adds -lm since libstdc++ uses libm. If we do it in gcc, we may
>>> add run-time dependency on libm.so to all C programs even if they
>>> don't use libm at all.
>>
>> No. All the gcc dr
On Thu, Dec 2, 2010 at 11:37 AM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> g++ adds -lm since libstdc++ uses libm. If we do it in gcc, we may
>> add run-time dependency on libm.so to all C programs even if they
>> don't use libm at all.
>
> No. All the gcc driver has to do is: *if* -lm i
"H.J. Lu" writes:
> g++ adds -lm since libstdc++ uses libm. If we do it in gcc, we may
> add run-time dependency on libm.so to all C programs even if they
> don't use libm at all.
No. All the gcc driver has to do is: *if* -lm is used on the link line,
also add it after the use of --plugin-call
On Thu, Dec 2, 2010 at 10:37 AM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> On Thu, Dec 2, 2010 at 9:41 AM, Ian Lance Taylor wrote:
>>> "H.J. Lu" writes:
>>>
How do you deal with -lm:
>>>
>>> I believe we have agreed that LTO can only introduce new symbol
>>> references that are sati
"H.J. Lu" writes:
> On Thu, Dec 2, 2010 at 9:41 AM, Ian Lance Taylor wrote:
>> "H.J. Lu" writes:
>>
>>> How do you deal with -lm:
>>
>> I believe we have agreed that LTO can only introduce new symbol
>> references that are satisfied by -lc and -lgcc. Under those conditions,
>
> Have you looked
On Thu, Dec 2, 2010 at 9:41 AM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> How do you deal with -lm:
>
> I believe we have agreed that LTO can only introduce new symbol
> references that are satisfied by -lc and -lgcc. Under those conditions,
Have you looked my testcase? The assumption of
"H.J. Lu" writes:
> How do you deal with -lm:
I believe we have agreed that LTO can only introduce new symbol
references that are satisfied by -lc and -lgcc. Under those conditions,
I believe my proposal will work just fine.
Again, my proposal is this:
I propose that we add a new linker o
On Thu, Dec 2, 2010 at 9:20 AM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> On Thu, Dec 2, 2010 at 9:00 AM, Ian Lance Taylor wrote:
>>> "H.J. Lu" writes:
>>>
I am not saying we should go with 2 stage linking. Just for clarification.
In 2 stage linking, the first stage only does s
"H.J. Lu" writes:
> On Thu, Dec 2, 2010 at 9:00 AM, Ian Lance Taylor wrote:
>> "H.J. Lu" writes:
>>
>>> I am not saying we should go with 2 stage linking. Just for clarification.
>>> In 2 stage linking, the first stage only does symbol resolution. The
>>> complete
>>> linking starts at the sec
On Thu, Dec 2, 2010 at 9:00 AM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> I am not saying we should go with 2 stage linking. Just for clarification.
>> In 2 stage linking, the first stage only does symbol resolution. The complete
>> linking starts at the second stage. So we don't do reall
"H.J. Lu" writes:
> I am not saying we should go with 2 stage linking. Just for clarification.
> In 2 stage linking, the first stage only does symbol resolution. The complete
> linking starts at the second stage. So we don't do really complete relink
> in 2 stage linking.
Understood. But you s
On Thu, Dec 2, 2010 at 6:52 AM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> On Wed, Dec 1, 2010 at 5:53 PM, Ian Lance Taylor wrote:
>>
>>> Or I'll rephrase: are there any cases for which using -pass-through for
>>> the set of libraries that the gcc driver automatically adds to the end
>>> o
"H.J. Lu" writes:
> On Wed, Dec 1, 2010 at 5:53 PM, Ian Lance Taylor wrote:
>
>> Or I'll rephrase: are there any cases for which using -pass-through for
>> the set of libraries that the gcc driver automatically adds to the end
>> of the link line would not be a complete solution?
>>
>> I'm not s
On Wed, Dec 1, 2010 at 11:44 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> On Wed, Dec 1, 2010 at 1:28 PM, Ian Lance Taylor wrote:
>>> "H.J. Lu" writes:
For linker script, archive, DSO and object file without IR,
*claimed will return 0 and plugin will save and pass it back to
>
On 02/12/2010 00:12, Cary Coutant wrote:
> Think about it -- any failure to bind to an interposed copy of memcpy
> (or any other library call generated by gcc) is indistinguishable from
> the compiler choosing to generate the code inline.
Indeed, replacing library functions is a tricky business
On 02/12/2010 04:28, Dave Korn wrote:
> I was going to test something like the attached.
Oops, there was a typo in that:
> @@ -637,7 +639,9 @@ proper position among the other output files. */
> -plugin %(linker_plugin_file) \
> -plugin-opt=%(lto_wrapper) \
> -plugin-opt=-fres
On 01/12/2010 23:06, Cary Coutant wrote:
>> My suspicion is that the LTO plugin can only introduce a small bounded
>> set of new symbol references, namely those which we assume can be
>> satisified from -lc or -lgcc. Is that true?
>
> Exactly.
Potentially also gcov, ssp, mudflap?
> The plug
On Wed, Dec 1, 2010 at 5:53 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> On Wed, Dec 1, 2010 at 4:48 PM, Ian Lance Taylor wrote:
>>> "H.J. Lu" writes:
>>>
__udivdi3 is just an example. It can also happen to memcpy, or
any library calls generated by GCC. I am enclosing a testc
"H.J. Lu" writes:
> On Wed, Dec 1, 2010 at 4:48 PM, Ian Lance Taylor wrote:
>> "H.J. Lu" writes:
>>
>>> __udivdi3 is just an example. It can also happen to memcpy, or
>>> any library calls generated by GCC. I am enclosing a testcase for memcpy.
>>
>> I believe we can solve that specific proble
On Wed, Dec 1, 2010 at 4:48 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> __udivdi3 is just an example. It can also happen to memcpy, or
>> any library calls generated by GCC. I am enclosing a testcase for memcpy.
>
> I believe we can solve that specific problem much more efficiently than
> >> I'm also not sure what you mean by "resolved IRONLY except that it is
> >> externally visible to the dynamic linker." If we're building a shared
> >> library, and the symbol is exported, it's not going to be IRONLY, and
> >> I don't see how it would be valid to optimize it out. If we're
> >
>
>> I'm also not sure what you mean by "resolved IRONLY except that it is
>> externally visible to the dynamic linker." If we're building a shared
>> library, and the symbol is exported, it's not going to be IRONLY, and
>> I don't see how it would be valid to optimize it out. If we're
>
> Well, the
"H.J. Lu" writes:
> __udivdi3 is just an example. It can also happen to memcpy, or
> any library calls generated by GCC. I am enclosing a testcase for memcpy.
I believe we can solve that specific problem much more efficiently than
requiring a complete link of all the input files. We currently
> I'm also not sure what you mean by "resolved IRONLY except that it is
> externally visible to the dynamic linker." If we're building a shared
> library, and the symbol is exported, it's not going to be IRONLY, and
> I don't see how it would be valid to optimize it out. If we're
Well, the typical
>> The only aspect of link
>> order that isn't maintained is the physical order of the sections in
>> memory.
>
> That is exactly the problem my proposal tries to address.
Really? That's not at all what PR 12248 is about. The physical order
of the sections (meaning the order of contributions withi
On Wed, Dec 1, 2010 at 3:06 PM, Cary Coutant wrote:
>>> That is what "Discard all previous inputs" in stage 2 linking is for.
>>
>> But what does that mean? Are you saying that the linker interface to
>> the plugin should change to work that way? If we do that, then we
>> should change other asp
>> That is what "Discard all previous inputs" in stage 2 linking is for.
>
> But what does that mean? Are you saying that the linker interface to
> the plugin should change to work that way? If we do that, then we
> should change other aspects of the plugin interface as well. It could
> probably
> If we get into extending linker plugin interface, it would be great if we
> would
> do somehting about COMDAT. We now have RESOLVED and RESOLVED_IRONLY, while
> the
> problem is that all non-hidden COMDAT symbols get RESOLVED that pretty much
> fixes them in the output library.
>
> I would pro
"H.J. Lu" writes:
> On Wed, Dec 1, 2010 at 1:28 PM, Ian Lance Taylor wrote:
>> "H.J. Lu" writes:
>>> For linker script, archive, DSO and object file without IR,
>>> *claimed will return 0 and plugin will save and pass it back to
>>> linker later in if it is specified at command line.
>>
>> I d
On Wed, Dec 1, 2010 at 1:33 PM, Richard Guenther
wrote:
> On Wed, Dec 1, 2010 at 10:28 PM, Ian Lance Taylor wrote:
>> "H.J. Lu" writes:
>>
>>> On Wed, Dec 1, 2010 at 12:55 PM, Ian Lance Taylor wrote:
"H.J. Lu" writes:
> On Wed, Dec 1, 2010 at 12:37 PM, Ian Lance Taylor wrote:
>>
On Wed, Dec 1, 2010 at 1:28 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> On Wed, Dec 1, 2010 at 12:55 PM, Ian Lance Taylor wrote:
>>> "H.J. Lu" writes:
>>>
On Wed, Dec 1, 2010 at 12:37 PM, Ian Lance Taylor wrote:
> Are you planning to have the plugin claim all files, even
On Wed, Dec 1, 2010 at 10:28 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> On Wed, Dec 1, 2010 at 12:55 PM, Ian Lance Taylor wrote:
>>> "H.J. Lu" writes:
>>>
On Wed, Dec 1, 2010 at 12:37 PM, Ian Lance Taylor wrote:
> Are you planning to have the plugin claim all files, eve
"H.J. Lu" writes:
> On Wed, Dec 1, 2010 at 12:55 PM, Ian Lance Taylor wrote:
>> "H.J. Lu" writes:
>>
>>> On Wed, Dec 1, 2010 at 12:37 PM, Ian Lance Taylor wrote:
>>>
Are you planning to have the plugin claim all files, even linker
scripts, and then pass only the command line files ba
On Wed, Dec 1, 2010 at 12:55 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> On Wed, Dec 1, 2010 at 12:37 PM, Ian Lance Taylor wrote:
>>
>>> Are you planning to have the plugin claim all files, even linker
>>> scripts, and then pass only the command line files back to the linker?
>>>
>>
>>
"H.J. Lu" writes:
> On Wed, Dec 1, 2010 at 12:37 PM, Ian Lance Taylor wrote:
>
>> Are you planning to have the plugin claim all files, even linker
>> scripts, and then pass only the command line files back to the linker?
>>
>
> Plugin will keep the same claim strategy. For those aren't claimed
On Wed, Dec 1, 2010 at 12:37 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> We don't want to put all unclaimed files passed to plugin back to linker.
>> On Linux,
>>
>> [...@gnu-6 gcc-lto]$ cat /usr/lib/libc.so
>> /* GNU ld script
>> Use the shared library, but some functions are only in
"H.J. Lu" writes:
> We don't want to put all unclaimed files passed to plugin back to linker.
> On Linux,
>
> [...@gnu-6 gcc-lto]$ cat /usr/lib/libc.so
> /* GNU ld script
>Use the shared library, but some functions are only in
>the static library, so try that secondarily. */
> OUTPUT_FOR
On Wed, Dec 1, 2010 at 11:12 AM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> On Wed, Dec 1, 2010 at 10:54 AM, Ian Lance Taylor wrote:
>>> "H.J. Lu" writes:
>>>
b. Compiler plugin controls what linker uses to generate the final
executable:
i. The linker c
"H.J. Lu" writes:
> On Wed, Dec 1, 2010 at 10:54 AM, Ian Lance Taylor wrote:
>> "H.J. Lu" writes:
>>
>>> b. Compiler plugin controls what linker uses to generate the final
>>> executable:
>>> i. The linker command line order should be the same, with or
>>> without LTO.
>>>
2010/12/1 Jan Hubicka :
>> On Wed, Dec 1, 2010 at 10:54 AM, Ian Lance Taylor wrote:
>> > "H.J. Lu" writes:
>> >
>> >> b. Compiler plugin controls what linker uses to generate the final
>> >> executable:
>> >> i. The linker command line order should be the same, with
>> >> or
> On Wed, Dec 1, 2010 at 10:54 AM, Ian Lance Taylor wrote:
> > "H.J. Lu" writes:
> >
> >> b. Compiler plugin controls what linker uses to generate the final
> >> executable:
> >> i. The linker command line order should be the same, with or
> >> without LTO.
> >> c. Add
On Wed, Dec 1, 2010 at 10:54 AM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> b. Compiler plugin controls what linker uses to generate the final
>> executable:
>> i. The linker command line order should be the same, with or
>> without LTO.
>> c. Add a cmdline bit f
"H.J. Lu" writes:
> b. Compiler plugin controls what linker uses to generate the final
> executable:
> i. The linker command line order should be the same, with or
> without LTO.
> c. Add a cmdline bit field to
> struct ld_plugin_input_file
> {
> c
On Wed, Dec 1, 2010 at 10:28 AM, Basile Starynkevitch
wrote:
> On Wed, 1 Dec 2010 10:18:58 -0800
> "H.J. Lu" wrote:
>
>> Here is a proposal to update LTO plugin interface.
>
> How should we parse the above sentence?
>
> Is it about an interface to plugin insi
On Wed, 1 Dec 2010 10:18:58 -0800
"H.J. Lu" wrote:
> Here is a proposal to update LTO plugin interface.
How should we parse the above sentence?
Is it about an interface to plugin inside binutils to support LTO?
Is it about an interface for GCC plugins to help them be more LTO
Hi,
Here is a proposal to update LTO plugin interface. Any comments?
Thanks.
--
H.J.
---
Goal: We should preserve the same linker command line order as if
there are no IR.
Problem:
a. LTO may generate extra symbol references which aren't in IR.
b. It was worked around
78 matches
Mail list logo
