https://sourceware.org/bugzilla/show_bug.cgi?id=19567
--- Comment #1 from Cary Coutant <ccoutant at gmail dot com> ---
Sorry, if there's a bug here that you're trying to describe, I don't see it.
Yes, I agree that the addend in Symbol_value::value() and
Merged_symbol_value::value() should be signed -- it really should be an
Elf_Swxword instead of Elf_Addr. But we're using two's complement arithmetic
and the generated code will be the same in either case, as Elf_Addr and
Elf_Swxword are both the same size.
Using Elf_Swxword for the addend should also apply in Relocate_functions in
reloc.h. But again, I don't see how that would change anything.
> Since addend is really signed, not unsigned, return type of
> Symbol_value::value is really signed.
Not true. The symbol value is still an Elf_Addr, which is defined as an
unsigned value. You can add unsigned + signed and still treat the result as
unsigned.
You mentioned PR 6658, which added this heuristic to check for a negative
addend:
if (addend < 0xffffff00)
I'll admit that I don't really understand why this heuristic was needed. If the
addend were instead signed, we should just be able to check for < 0. The
comment above that line suggests that a 64-bit ELF object may still have a
32-bit addend, but that would be true only for targets using SHT_REL, where the
addend comes from the section contents. Our SHT_REL targets are all 32-bit, so
I'd think we'd always be getting a properly sign-extended addend.
What is the real problem you're seeing?
--
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
