[Bug gold/21894] New: gdb-index fails to parse debug_ranges base address specifiers in 32 bit address files

[dblaikie at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21894

            Bug ID: 21894
           Summary: gdb-index fails to parse debug_ranges base address
                    specifiers in 32 bit address files
           Product: binutils
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gold
          Assignee: ccoutant at gmail dot com
          Reporter: dblaikie at gmail dot com
                CC: ian at airs dot com
  Target Milestone: ---

LLVM recently gained support for using DWARF debug_range base address
specifiers to reduce relocations.

This broke Chromium builds using gold's gdb-index in a 32 bit build. 

https://bugs.llvm.org/show_bug.cgi?id=34007

Looks like this is a bug in gold's parsing of debug_range. From the last
comment in the above bug:

"Yep, gold bug in parsing 32 bit range lists. The value in the table is read as
32 bit unsigned, widened to long, then compared to -1."

"Here's a dodgy change but at least demonstrates that gold seems to work fine
with this issue addressed:

---
../.citc/baseline/google3/third_party/binutils/binutils/gold/dwarf_reader.cc   
    2017-06-22 19:38:27.000000000 -0700
+++ third_party/binutils/binutils/gold/dwarf_reader.cc  2017-07-31
16:48:58.000000000 -0700
@@ -442,12 +442,12 @@
         break;

       // A "base address selection entry" is identified by
       // 0xffffffff for the first value of the pair.  The second
       // value is used as a base for subsequent range list entries.
-      if (shndx1 == 0 && start == -1)
-       base = end;
+      if (shndx1 == 0 && start == (addr_size == 4 ? 4294967295 : -1))
+        base = end;
       else if (shndx1 == shndx2)
        {
          if (shndx1 == 0 || object->is_section_included(shndx1))
            ranges->add(shndx1, base + start, base + end);
        }

A little above in the code the 'start' value is read as an unsigned 4 byte int,
widened into an signed 8 byte int, which doesn't sign extend (since it wasn't
signed)."

-- 
You are receiving this mail because:
You are on the CC list for the bug.