https://sourceware.org/bugzilla/show_bug.cgi?id=22820
Cary Coutant <ccoutant at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #1 from Cary Coutant <ccoutant at gmail dot com> ---
The two functions do have different relocations, so the linker should be
able to tell them apart. Unfortunately, gold is factoring in the
relocation addends when it shouldn't. References to items in a merge
section use a local symbol to point to the item, and use the addend
only to correct for a pc-relative bias (or for some other form of
non-zero base). Therefore, when the relocation points to a non-section
symbol, we should ignore the addend when trying to figure out which
item in the merge section we're pointing to (and then add the addend
back in only after identifying that target).
GCC 7 with -O produced a slightly different form of bias. In earlier
versions, we would see a small negative bias (e.g., .LC1 - 4), and
the code was ignoring those small negative biases (correctly, but for
the wrong reason). As a result, we were identifying the correct targets
and refusing to fold the two functions. With the new code, we're seeing
positive biases (e.g., .LC1 + 6 and .LC2 + 6). If we don't ignore the
addends, we look at the two strings, but we are ignoring the first 6
characters of each string. In this test case, the differences between
the two strings are only in the first character, so we mistakenly
conclude that the functions really are identical!
Even though the results are very different, this is the same bug as
PR 20642.
*** This bug has been marked as a duplicate of bug 20642 ***
--
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
