This is the mail archive of the dwarf2@corp.sgi.com mailing list for the dwarf2 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: location lists


David B Anderson wrote:
> 
> |>    Right here is where you lose me.  DWARF doesn't describe references to
> |>    global symbols; it only describe declarations & definitions.  So, how can
> |>    a debugger know if there is a reference in the current context?  Surely
> |>    you're not talking about requiring a vendor extension to get this right?
> |>    Maybe you're talking about deducing the presence of a reference by looking
> |>    for a replicated global definition (which is problematic for Ada's
> |>    describe-an-object-once-only approach)?
> |
> |If there is a reference to a variable in the current context, there must
> |be a declaration.
> 
> Normally (to save space) declarations are ignored in dwarf
> (except in special cases, mentioned in the dwarf2 spec).
> 
> The suggestion is that a non-defining
> declaration have a location list?
> 
> But section 4.1 (draft 5 page 53) says non-defining declarations
> are not allowed to have a location attribute (bullet 3.).
> (the words are just a tiny bit soft, but that's how I read it).

Let's say you have the following code in A.c:

	extern int i;

	foo ()
	{
		for (i=0; i < 100; i++) {
		...
		}
	}

If the compiler moves i into a register, I would hope that
there would be some way to describe its lifetime.  Is 
"extern int i" a defining declaration?  Only the linker 
knows for sure.

Section 4.1 does prohibit location expressions for 
non-defining declarations.  But see section 2.12 which 
mentions that a debugger might need a DIE for a non-defining 
declaration to be able to evaluate an expression.  Seems
like this might be one case where this might apply.

If there is a defining declaration for "int i = 0;"  in B.c,
then a location expression with the declaration couldn't
describe that it was in a register in a A.c.

I'm not sure exactly why section 4.1 contains the prohibition.
I think it had something to do with prototypes.

-- 
Michael Eager	 Eager Consulting     eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]