[Bug gold/20642] internal error in get_section_contents, at icf.cc:467 with --icf=safe

[ccoutant at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20642

Cary Coutant <ccoutant at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2018-04-24
           Assignee|tmsriram at google dot com         |ccoutant at gmail dot 
com
     Ever confirmed|0                           |1

--- Comment #12 from Cary Coutant <ccoutant at gmail dot com> ---
Here's a disassembly of the first part of the function in section 150:

Disassembly of section
.text._D3std8encoding__T6decodeTAxEQBbQBa10Latin2CharZQBeFNaNbNiNfKQBjZw:

00000000 <_D3std8encoding__T6decodeTAxEQBbQBa10Latin2CharZQBeFNaNbNiNfKQBjZw>:
   0:   53                      push   %ebx
   1:   56                      push   %esi
   2:   50                      push   %eax
   3:   89 c1                   mov    %eax,%ecx
   5:   e8 00 00 00 00          call   a
<_D3std8encoding__T6decodeTAxEQBbQBa10Latin2CharZQBeFNaNbNiNfKQBjZw+0xa>
   a:   5b                      pop    %ebx
   b:   8b 11                   mov    (%ecx),%edx
   d:   81 c3 05 00 00 00       add    $0x5,%ebx
                        f: R_386_GOTPC  _GLOBAL_OFFSET_TABLE_
  13:   85 d2                   test   %edx,%edx
  15:   74 2d                   je     44
<_D3std8encoding__T6decodeTAxEQBbQBa10Latin2CharZQBeFNaNbNiNfKQBjZw+0x44>
  17:   8b 71 04                mov    0x4(%ecx),%esi
  1a:   4a                      dec    %edx
  1b:   0f b6 06                movzbl (%esi),%eax
  1e:   46                      inc    %esi
  1f:   89 11                   mov    %edx,(%ecx)
  21:   89 71 04                mov    %esi,0x4(%ecx)
  24:   3d a1 00 00 00          cmp    $0xa1,%eax
  29:   72 13                   jb     3e
<_D3std8encoding__T6decodeTAxEQBbQBa10Latin2CharZQBeFNaNbNiNfKQBjZw+0x3e>
  2b:   8d 88 5f ff ff ff       lea    -0xa1(%eax),%ecx
  31:   83 f9 5e                cmp    $0x5e,%ecx
  34:   77 27                   ja     5d
<_D3std8encoding__T6decodeTAxEQBbQBa10Latin2CharZQBeFNaNbNiNfKQBjZw+0x5d>
  36:   0f b7 84 43 be fe ff    movzwl -0x142(%ebx,%eax,2),%eax
  3d:   ff 
                        3a: R_386_GOTOFF        .L.str.69

(Side question: where does this name mangling scheme come from? It's not the
standard C++ scheme.)

We have there at offset 0x36 a reference to .L.str.69 - 0x142 (aka 0xfffffebe).
That symbol is a local symbol defined at offset 0 in section 2386:

    52: 00000000   192 OBJECT  LOCAL  DEFAULT 2386 .L.str.69

And section 2386 is a string merge section:

  [2386] .rodata.str2.16   PROGBITS        00000000 011eb0 000322 02 AMS  0   0
16

I'm not sure what that -0x142 offset is being used for, but I'll have to assume
that the instruction is meant to address the string at .L.str.69, and the
offset is compensation for some positive offset introduced elsewhere. In other
words, for the purposes of figuring out what piece of the merge section we're
referencing, we should ignore the addend.

We have a heuristic to determine whether we should ignore the addend or not in
these cases -- we treat an addend in the range 0xffffff00-0xffffffff as a small
negative addend as a compensation for a pc-relative reference, and ignore it.
We treat everything else as a positive addend and consider it as part of the
expression to determine what item is being referenced.

Unfortunately, that heuristic should only be applied for pc-relative
relocations, and only for references to section symbols. Neither of those
conditions apply here, and we should ignore the addend regardless of its value.
For relocating the code normally, that is the case, and we should generate the
right code eventually. For --icf, however, we are incorrectly applying that
heuristic to this case, and that's leading to this error.

-- 
You are receiving this mail because:
You are on the CC list for the bug.