[Bug lto/91228] [10 regression] Removing gnu_lto_v1 symbol name breaks LTO with Solaris ld
marxin at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Tue Jul 23 08:58:00 GMT 2019
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91228
--- Comment #4 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #3)
> I think I warned you in a followup to your mail(In reply to Martin Liška
> from comment #1)
> > Obviously mine.
> > @Richi: Have you seen anything similar to this?
>
> I think I warned you in a followup to your mail that likely the renaming
> is going to break since the first zero byte is the same as "no name" which
> both Solaris and HPUX don't like. I suggested to change
>
> /* Find the first '\0' in strings. */
> zero_byte = (char *) memchr (strings, '\0', strsz);
>
> to
>
> /* Find the first '\0' in strings. */
> zero_byte = (char *) memchr (strings + 1, '\0', strsz);
>
> but then Jeff approved the original...
Meh, I made the +1 at a wrong place. The correction patch should look like:
diff --git a/libiberty/simple-object-elf.c b/libiberty/simple-object-elf.c
index bdee963634d..75159266596 100644
--- a/libiberty/simple-object-elf.c
+++ b/libiberty/simple-object-elf.c
@@ -1388,8 +1388,8 @@ simple_object_elf_copy_lto_debug_sections
(simple_object_read *sobj,
(unsigned char *)strings,
strsz, &errmsg, err);
/* Find first '\0' in strings. */
- gnu_lto = (char *) memchr (gnu_lto, '\0',
- strings + strsz - gnu_lto + 1);
+ gnu_lto = (char *) memchr (gnu_lto + 1, '\0',
+ strings + strsz - gnu_lto);
/* Read the section index table if present. */
if (symtab_indices_shndx[i - 1] != 0)
{
@Rainer: Does the patch work for you?
>
> See all the glory details in PR83452 which you now uncovered again.
>
> Note that a way out would be to append 'gnu_lto_v1' to .strings and
> use the same name as before. As said, eventually an empty name does it
> (but you can't use the empty name at offset zero).
>
> > @Rainer: About what linker are we talking?
More information about the Gcc-bugs
mailing list