This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix PR83452
- From: Alan Modra <amodra at gmail dot com>
- To: Richard Biener <rguenther at suse dot de>
- Cc: gcc-patches at gcc dot gnu dot org, dave dot anglin at bell dot net, ro at CeBiTec dot Uni-Bielefeld dot DE
- Date: Wed, 20 Dec 2017 15:50:34 +1030
- Subject: Re: [PATCH] Fix PR83452
- Authentication-results: sourceware.org; auth=none
- References: <alpine.LSU.2.20.1712191530500.12252@zhemvz.fhfr.qr>
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