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.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
