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

[hjl.tools at gmail dot com]

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.