This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: LTO symtab sections vs. missing symbols (libcalls maybe?) and lto-plugin vs. COFF
On Thu, Oct 14, 2010 at 5:28 PM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
> On 14/10/2010 15:44, Richard Guenther wrote:
>> On Thu, Oct 14, 2010 at 4:59 PM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
>
>>> ?Nor indeed is there any sign of puts, which is what the generated ltrans0.s
>>> file ends up optimising it to (as indeed does the native code in the original
>>> .o file). ?I'm assuming that this is by design and is for some reason along
>>> the lines that we don't even know whether or which function calls are actually
>>> going to be emitted until link time?
>>
>> I think this is because builtin functions are handled specially (their decls
>> are not streamed, likewise I think we don't stream their cgraph nodes).
>
> ?Ah, yes; -fno-builtin avoids it, for example.
>
>> As you noted we may eventually fold printf to puts (we may also generate
>> a memcpy call out of an aggregate assignment), so it might not make
>> your life perfect if we emit symbols for those calls (as indeed we don't know
>> which ones we will emit at link time).
>
> ?Yes, I can see that we'd quite possibly end up with unused library code
> pulled into the link.
>
>>> ?It makes life complicated in the linker though, because it means there are
>>> symbols present in the object files that the plugin adds via the
>>> add_input_files callback that weren't in the original symbols the linker
>>> presented via add_symbols when it initially claimed the object file containing
>>> the IR.
>>>
>>> ?The consequence of this is that either there are going to be undefined
>>> symbols in the final executable, or the linker has to perform another round of
>>> library scanning. ?It occurred to me that the semantics of this might even not
>>> have been decided yet, since ELF platforms are perfectly happy with undefined
>>> symbols at final link time. ?The only documentation I know of that specifies
>>> the linker plugin API is the GCC wiki whopr/driver page(*), and it doesn't say
>>> anything explicit about this; maybe I've failed to infer something that I
>>> should have.
>>
>> Yeah, I think you have to deal with undefined references to "standard"
>> functions (mostly from libc, libm but maybe also from libpthread or so).
>
> ?Well, the thing I'm trying to figure out is how to deal with them. ?COFF
> doesn't allow undefined references in executables.
>
>>> ?So, is there a defined way in which this is supposed to work? ?And if the
>>> linker is supposed to rescan the libs after the plugin adds files, is it
>>> supposed to offer any archive members it finds to the plugin for claiming?
>>> Should there be multiple iterations of claiming files and calling
>>> all_symbols_read? ?And if not, what about if the archive members we find on
>>> the second pass contain LTO IR?
>>>
>>> ?It occurs to me that maybe this is what the add_input_library hook is for:
>>> perhaps a simple fix would be for collect2 to pass a list of all the stdlibs
>>> to the plugin as a plugin option, and it could add_input_library them after
>>> it's finished adding object files. ?Would that be a reasonable approach?
>>>
>>> ?(Right now I have a "working" COFF lto-plugin, but the link fails with
>>> unresolved symbols unless I manually add (e.g.) "-Wl,-u,_puts (... etc.)" to
>>> the command-line to make sure all the required libc archive members get pulled
>>> in during the first pass over libs!)
>>
>> I have no idea about the linker-plugin side, but we could of course
>> avoid generating any calls that were not there before (by for example
>> streaming builtin decls and only if they are used). ?But that's as much
>> a workaround as fixing things up in the linker afterwards ...
>
> ?Sorry, I don't quite understand that suggestion! ?Do you mean we'd emit a
> symbol for printf and that would result in an explicit printf which wouldn't
> have the chance of being optimised to a puts at link-time?
Yes.
> If so I see how
> it'd work, but it would be a shame to lose optimisation in LTO. ?Or to include
> unnecessary library members. ?I *think* that re-adding the stdlibs after all
> the new input files in the plugin might work, but haven't tried it yet.
>
> ?I have the same problem with '__main', BTW. ?Is that supposed to count as a
> builtin, or do we need to do something in expand_main_function() to make LTO
> aware when it calls __main?
Hm, I don't know - I suppose that's from the crt*.o stuff? The main
function itself should already appear in the symbols.
Richard.
>
> ? ?cheers,
> ? ? ?DaveK
>
>
>