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 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? 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?
cheers,
DaveK