On Wed, 20 Dec 2017, Alan Modra wrote: > On Tue, Dec 19, 2017 at 03:37:10PM +0100, Richard Biener wrote: > > + while ((gnu_lto = memchr (gnu_lto, 'g', > > + strings + strsz - gnu_lto))) > > + if (strncmp (gnu_lto, "gnu_lto_v1", > > + strings + strsz - gnu_lto) == 0) > > Could be strcmp, I believe. Entries in .strtab are NUL terminated. > The first byte of .strtab is always NUL too. > > A thought occurred to me when looking at the patch. If gcc emitted > "____gnu_lto_v1" as well as "__gnu_lto_v1" then this code could look > for the former symbol and use it as a replacement. That would avoid > the user namespace symbol we're emitting here.
The issue is that the symbol is hardcoded in ld IIRC to trigger plugin autoloading / diagnostics. So if we re-emit either then we'll get infinite recursion. As much as it was convenient to detect whether we have an object with LTO bytecode by using a symbol simply keying on the LTO section names would have been better .... (harder to do with the non-plugin path which just uses nm to look for the LTO signature). I've installed the patch as-is. > With .strtab string > tail merging the cost would be two extra bytes in .strtab and one > extra symbol, 20 or 24 bytes in .symtab, per lto object file. > (A target that adds leading underscores to symbols would complicate > things a little for the above code, and is why it is necessary to add > two extra underscores to the replacement symbol. Currently gcc looks > for "__gnu_lto_v1" and "___gnu_lto_v1", while ld, gold, ar, nm look > for "__gnu_lto_slim" and "___gnu_lto_slim".. So another possibility > would be for gcc to switch to using "__gnu__LTO_v1", with the > replacement being "__LTO_v1". Or emit an entirely new symbol just to > use as a replacement.) Appending something to the string section would be indeed possible as well. Richard.
