gcc -gdwarf-2 -gstrict-dwarf produces bad debug_loc entries

[Trevor Harrison]

I'm running into an issue with start/end values of debug_loc entries
being absolute addresses instead of offsets when a file is compiled
with -gdwarf-2 and -gstrict-dwarf and there are virtual methods in
that file.  gcc 4.4.7, but I've seen it under 4.8'ish.

I'm new enough to dwarf stuff to not be 100% sure that this is a bug
vs. I'm just missing a field somewhere that indicates that these
debug_loc entries are in a different format.... but on the other hand,
readelf also seems confused about this.

An example file:

#include <stdio.h>
struct class1
{
    class1() { printf("blah\n"); }
    virtual ~class1() { }
};

int main()
{
    class1 c1;
    return 0;
}

# g++ -gdwarf-2 -gstrict-dwarf -o foo foo.cpp
# readelf -W -w -x .debug_loc foo > foo.debuginfo

from the foo.debuginfo file:

The compile_unit shows 0x400664 as its lowpc:

 <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
    < c>   DW_AT_producer    : (indirect string, offset: 0xab): GNU
C++ 4.4.7 20120313 (Red Hat 4.4.7-17)
    <10>   DW_AT_language    : 4        (C++)
    <11>   DW_AT_name        : (indirect string, offset: 0x29): foo.cpp
    <15>   DW_AT_comp_dir    : (indirect string, offset: 0x41): <snipped>
    <19>   DW_AT_low_pc      : 0x400664
    <21>   DW_AT_high_pc     : 0x400693
    <29>   DW_AT_stmt_list   : 0x0

But the debug_loc section shows start addresses in the 0x80000 range:

Contents of the .debug_loc section:

    Offset   Begin    End      Expression
    00000000 0000000000800cf8 0000000000800cf9 (DW_OP_breg7: 8)
    00000000 0000000000800cf9 0000000000800cfc (DW_OP_breg7: 16)
    00000000 0000000000800cfc 0000000000800d1a (DW_OP_breg6: 16)
    00000000 0000000000800d1a 0000000000800d1b (DW_OP_breg7: 8)
    00000000 <End of list>

(800cf8 == lowpc 0x400664 + 0x400694)

Hex dump of section '.debug_loc':
  0x00000000 94064000 00000000 95064000 00000000 ..@.......@.....
  0x00000010 02007708 95064000 00000000 98064000 ..w...@.......@.
  0x00000020 00000000 02007710 98064000 00000000 ......w...@.....
  0x00000030 b6064000 00000000 02007610 b6064000 ..@.......v...@.
  0x00000040 00000000 b7064000 00000000 02007708 ......@.......w.


Is this is a known bug or issue or am I missing something?