.debug_loc

.debug_loc

[Michal Ludvig]

Hi Daniel,
I have a question on parsing .debug_loc on x86-64. Let's have this one:

         .section        .debug_loc,"",@progbits
.LLST0:
         .quad   .LVL3-.text     # Location list begin address (*.LLST0)
         .quad   .LVL5-.text     # Location list end address (*.LLST0)
         .value  0x1     # Location expression size
         .byte   0x53    # DW_OP_reg3
         [...]
         .quad   .LVL16-.text    # Location list begin address (*.LLST0)
         .quad   .Letext0-.text  # Location list end address (*.LLST0)
         .value  0x1     # Location expression size
         .byte   0x53    # DW_OP_reg3
         .long   0x0     # Location list terminator begin (*.LLST0)
         .long   0x0     # Location list terminator end (*.LLST0)
.LLST1:
         .quad   .LVL10-.text    # Location list begin address (*.LLST1)
         .quad   .LVL11-.text    # Location list end address (*.LLST1)
         [...]

As you can see, addresses of ranges are 64b (.quad) BUT the terminating 
zeroes are only 32b long (.long). Is it an intent or a bug? If it's 
correct, than how do I realise that I've reached the end of LLST0? Maybe 
because the address (.long+.long = .quad = 0) is lower that any of the 
previous ones? I can't tell that I'm at the end if I just see a NULL 
address, because IMHO it's perfectly correct for a range to start at the 
very beginning of .text section. Is it a bug or not?

And one more thing - how do I distinguish whether a given DIE has the 
attribute "in-place" or linked in .debug_loc? The only difference I 
could find was the appropriate record for DW_AT_location in 
.debug_abbrev, where for "in-place" case was the value DW_FORM_blockN 
while for loclist entries it was DW_FORM_data4. Can I rely on this fact 
or is there a better way to differentiate these cases?
BTW Is it correct to have the pointer as DW_FORM_data4 and not as 
DW_FORM_data8 even on 64b machine?

Thanks for information.

Michal Ludvig
-- 
* SuSE CR, s.r.o     * mludvig@suse.cz
* (+420) 296.545.373 * http://www.suse.cz

Re: .debug_loc

[Keith Walker]

Michal,

At 17:52 31/01/2003 +0100, Michal Ludvig wrote:
>Hi Daniel,
>I have a question on parsing .debug_loc on x86-64. Let's have this one:
>
>         .section        .debug_loc,"",@progbits
>.LLST0:
>         .quad   .LVL3-.text     # Location list begin address (*.LLST0)
>         .quad   .LVL5-.text     # Location list end address (*.LLST0)
>         .value  0x1     # Location expression size
>         .byte   0x53    # DW_OP_reg3
>         [...]
>         .quad   .LVL16-.text    # Location list begin address (*.LLST0)
>         .quad   .Letext0-.text  # Location list end address (*.LLST0)
>         .value  0x1     # Location expression size
>         .byte   0x53    # DW_OP_reg3
>         .long   0x0     # Location list terminator begin (*.LLST0)
>         .long   0x0     # Location list terminator end (*.LLST0)

These last 2 entries should be .quad in this case (as the DWARF3 
specification states:

         "The end of a given location list is marked by an
          end of list entry, which consists of a 0 for the
          beginning address and a 0 for the ending address."

This looks like a compiler defect not correctly catering for the 64-bit 
addresses in the terminating entry.

>.LLST1:
>         .quad   .LVL10-.text    # Location list begin address (*.LLST1)
>         .quad   .LVL11-.text    # Location list end address (*.LLST1)
>         [...]
>
>As you can see, addresses of ranges are 64b (.quad) BUT the terminating 
>zeroes are only 32b long (.long). Is it an intent or a bug? If it's 
>correct, than how do I realise that I've reached the end of LLST0? Maybe 
>because the address (.long+.long = .quad = 0) is lower that any of the 
>previous ones? I can't tell that I'm at the end if I just see a NULL 
>address, because IMHO it's perfectly correct for a range to start at the 
>very beginning of .text section. Is it a bug or not?
>
>And one more thing - how do I distinguish whether a given DIE has the 
>attribute "in-place" or linked in .debug_loc? The only difference I could 
>find was the appropriate record for DW_AT_location in .debug_abbrev, where 
>for "in-place" case was the value DW_FORM_blockN while for loclist entries 
>it was DW_FORM_data4. Can I rely on this fact or is there a better way to 
>differentiate these cases?

That is the correct way to distinguish the 2 cases.

>BTW Is it correct to have the pointer as DW_FORM_data4 and not as 
>DW_FORM_data8 even on 64b machine?

These a "offsets" rather than pointers, and where they are used you can use 
either form provided the selected form is capable of holding the required 
offset.       Note that the actual offset required may not be known until 
link time :-)

Keith

Re: .debug_loc

[Daniel Berlin]

On Fri, 31 Jan 2003, Keith Walker wrote:

> Michal,
>
> At 17:52 31/01/2003 +0100, Michal Ludvig wrote:
> >Hi Daniel,
> >I have a question on parsing .debug_loc on x86-64. Let's have this one:
> >
> >         .section        .debug_loc,"",@progbits
> >.LLST0:
> >         .quad   .LVL3-.text     # Location list begin address (*.LLST0)
> >         .quad   .LVL5-.text     # Location list end address (*.LLST0)
> >         .value  0x1     # Location expression size
> >         .byte   0x53    # DW_OP_reg3
> >         [...]
> >         .quad   .LVL16-.text    # Location list begin address (*.LLST0)
> >         .quad   .Letext0-.text  # Location list end address (*.LLST0)
> >         .value  0x1     # Location expression size
> >         .byte   0x53    # DW_OP_reg3
> >         .long   0x0     # Location list terminator begin (*.LLST0)
> >         .long   0x0     # Location list terminator end (*.LLST0)
>
> These last 2 entries should be .quad in this case (as the DWARF3
> specification states:
>
>          "The end of a given location list is marked by an
>           end of list entry, which consists of a 0 for the
>           beginning address and a 0 for the ending address."
>
> This looks like a compiler defect not correctly catering for the 64-bit
> addresses in the terminating entry.
Yeah, my bad.
I'll fix it.