This is the mail archive of the
elfutils-devel@sourceware.org
mailing list for the elfutils project.
Re: Using dwfl to enumerate frames of current thread
- From: Mark Wielaard <mjw at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Thu, 20 Aug 2015 19:39:37 +0200
- Subject: Re: Using dwfl to enumerate frames of current thread
On Thu, 2015-08-20 at 19:32 +0200, Mark Wielaard wrote:
> On Thu, 2015-08-20 at 10:06 -0700, Josh Stone wrote:
> > On 08/20/2015 08:32 AM, Mark Wielaard wrote:
> > > See Dwarf 4 2.17 Code Addresses and Ranges. In particular elfutils takes
> > > advantage of:
> > > "If an entity has no associated machine code, none of these attributes
> > > are specified."
> >
> > (A -> B) does not give you (B -> A)!
> >
> > That is, the spec does *not* say "If none of these attributes are
> > specified, the entity has no associated machine code."
>
> Maybe the spec needs clarification that is what is actually meant. Or
> you can see it as a quality of implementation issue. But it is what we
> need and what we rely on. Otherwise you have no way to know whether or
> not to scan a whole CU or DIE subtree for program scope DIEs. And always
> scanning each and every subtree just in case some program scope DIE is
> hiding deep down is just silly.
I see it is in the non-normative text of 6.1 Accelerated Access:
To find the debugging information associated with a subroutine,
given an address, a debugger can use the low and high pc
attributes of the compilation unit entries to quickly narrow
down the search
So, yes, it is non-normative, but it still makes a lot of sense :)
Cheers,
Mark