On Thu, Oct 14, 2010 at 5:28 PM, Dave Korn <dave.korn.cyg...@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.cyg...@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 > > >