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. 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.) -- Alan Modra Australia Development Lab, IBM
