> > what about allowing -flinker-output=XXX at link time as a driver option > and avoiding to override it if already present?
That sounds good. I will implement that. > > > > > struct cgraph_node *node = order[i]; > > > > > > > > - if (node->has_gimple_body_p ()) > > > > + if (gimple_has_body_p (node->decl)) > > > > > > ? > > > > node->has_gimple_body_p returns true for if gimple body is available, but > > not neccesarily > > read to memory (in WPA), while gimple_has_body_p returns true only when > > body is in memory. > > The statement renumbering which is guarded is not needed if we only shuffle > > the sections > > (and will ICE) > > > > + /* It would be cool to produce .o file directly, but our current > > > > + simple objects does not contain the lto symbol markers. Go > > > > the slow > > > > + way through the asm file. */ > > > > > > We should get away from the symbol markers and instead rely on section > > > names. Not in this patch of course. > > > > Yes, we need to get simple-object interface somehow working here. The > > symbols > > markers are documented by the LTO specification. I do not mind that much > > of changing > > it. > > For your debug work, I think simple-object will need quite some work to > > output > > dwarf anyway. Perhaps something that can be done as part of SoC? > > Well, my plan is still to not rely on simple-object but have binutils > fixed for the issues I encounter. Well, I still hope we will be able to bypass the useless asm step with slim LTO. For that we need simple object capable of outputting object file with those symbols & the debug info once early debug lands. > > But yes, if we go the simple-object route we need to handle adding > symbols and parsing and rewriting relocations (ugh). Basically > simple-object needs to handle full partial linking under the > constraint of all relocations being involed not needing resolving > but only (offset) rewriting. Yep, that sounds bit too involved. See the ohter email about HJ's binutils > > Well, "ships", yes. But with plugin auto-loading in ld we end up > with a single lto-plugin.so file in the auto-load path and choosing > the "newest" is supposed to work with older GCC as well ... > > Of course plugin auto-loading is used for ar and friends which > might not be affected here. auto-loading isn't important for > ld itself (it won't work without using the GCC driver and the > GCC driver indeed explicitely loads its own plugin). > > So maybe it's an on-issue... Yep, I think the lto-plugin currently won't start GCC unless called from driver that chose proper plugin. So hope we are safe here. Honza > > Richard.
