* .debug_loc
@ 2003-01-31 18:06 Michal Ludvig
2003-01-31 18:07 ` .debug_loc Keith Walker
0 siblings, 1 reply; 3+ messages in thread
From: Michal Ludvig @ 2003-01-31 18:06 UTC (permalink / raw)
To: Daniel Berlin; +Cc: gcc
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: .debug_loc
2003-01-31 18:06 .debug_loc Michal Ludvig
@ 2003-01-31 18:07 ` Keith Walker
2003-01-31 19:02 ` .debug_loc Daniel Berlin
0 siblings, 1 reply; 3+ messages in thread
From: Keith Walker @ 2003-01-31 18:07 UTC (permalink / raw)
To: Michal Ludvig, Daniel Berlin; +Cc: gcc
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: .debug_loc
2003-01-31 18:07 ` .debug_loc Keith Walker
@ 2003-01-31 19:02 ` Daniel Berlin
0 siblings, 0 replies; 3+ messages in thread
From: Daniel Berlin @ 2003-01-31 19:02 UTC (permalink / raw)
To: Keith Walker; +Cc: Michal Ludvig, gcc
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2003-01-31 17:53 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-01-31 18:06 .debug_loc Michal Ludvig
2003-01-31 18:07 ` .debug_loc Keith Walker
2003-01-31 19:02 ` .debug_loc Daniel Berlin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).