https://sourceware.org/bugzilla/show_bug.cgi?id=19567
Bug ID: 19567
Summary: Symbol_value::value doesn't support x32 overflow check
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: hjl.tools at gmail dot com
CC: ian at airs dot com
Target Milestone: ---
class Symbol_value
typedef typename elfcpp::Elf_types<size>::Elf_Addr Value;
Value
value(const Sized_relobj_file<size, big_endian>* object, Value addend) const
{
if (this->has_output_value_)
return this->u_.value + addend;
Since x32 is 32-bit software convention for 64-bit hardware, the address
wraparound is 64-bit, not 32-bit. It leads to a problems for x32. Since
addend is really signed, not unsigned, return type of Symbol_value::value
is really signed. But one can't tell return value 0xffffffff is -1 or
4294967295.
Also object.h has
value(const Relobj* object, unsigned int input_shndx, Value addend) const
{
// This is a relocation against a section symbol. ADDEND is the
// offset in the section. The result should be the start of some
// merge area. If the object file wants something else, it should
// use a regular symbol rather than a section symbol.
// Unfortunately, PR 6658 shows a case in which the object file
// refers to the section symbol, but uses a negative ADDEND to
// compensate for a PC relative reloc. We can't handle the
// general case. However, we can handle the special case of a
// negative addend, by assuming that it refers to the start of the
// section. Of course, that means that we have to guess when
// ADDEND is negative. It is normal to see a 32-bit value here
// even when the template parameter size is 64, as 64-bit object
// file formats have 32-bit relocations. We know this is a merge
// section, so we know it has to fit into memory. So we assume
// that we won't see a value larger than a large 32-bit unsigned
// value. This will break objects with very very large merge
// sections; they probably break in other ways anyhow.
It indicates that addend should be signed, not unsigned.
--
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
