[LLVMbugs] [Bug 10105] New: DWARF compile_unit is missing AT_low_pc attribute

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=10105

           Summary: DWARF compile_unit is missing AT_low_pc attribute
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Core LLVM classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: wiml at omnigroup.com
                CC: llvmbugs at cs.uiuc.edu


The compilation unit DIE emitted by llvm is missing the low_pc attribute, which
is necessary in order to interpret location lists (AT_location) and range lists
(AT_ranges) referred to by that DIE's debug information.

OTOH, llvm does emit an entry_pc attribute whose value is what I'd expect the
low_pc to be. This may be a misreading of a remark in 2.18, which says that if
the entry_pc is missing, then a consumer can assume that it's the same as
low_pc; perhaps llvm simply gets this backwards? At any rate, DWARF doesn't
define a meaning for entry_pc when found in a compilation unit, so it seems
like an error.

For reference see the following bits of the DWARF4 spec (iiirc, there's no
substantial difference here wrt DWARF3):
  Section 3.1.1, last paragraph.
  Section 3.1.1, top of p.44
For the use of the compilation unit's base address in location lists and range
lists: 2.6.2; 2.17.3

Here's a snippet of dwarfdump output:

0x0000000b: TAG_compile_unit [1] *
             AT_producer( "clang version 3.0 (trunk 132731)" )
             AT_language( DW_LANG_C99 )
             AT_name( "split.c" )
             AT_entry_pc( 0x0000000000000000 )
             AT_stmt_list( 0x00000000 )
             AT_comp_dir( "/Volumes/Local/wiml/netsrc/llvm.org/build" )
             AT_APPLE_optimized( 0x01 )

[....]
0x0000008f:         TAG_formal_parameter [3]  
[....]
                     AT_location( 0x00000000
                        0x0000000000000000 - 0x000000000000000c: rdi
                        0x000000000000000c - 0x000000000000001f: rbx )


Note that there's no explicit base address entry in the location list
(hex-dumping the debug_loc section confirms this), and therefore it relies on
the base address given by the containing compilation unit.

I just tested against clang trunk r132731, and the versions shipped with
Apple's Xcode 3.x behave the same way.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.