[Bug gold/19567] Symbol_value::value doesn't support x32 overflow check

[ccoutant at gmail dot com]

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.