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: Replicated Dwarf [was Re: location lists]


>>>>> "Michael" == Michael Eager <eager@eagercon.com> writes:

> An AT_declaration is used for non-defining declarations of a 
> variable.  The current specification prohibits location lists
> for these declarations, for reasons which are not clear.  
> A reasonable interpretation for a location list for a non-
> defining declaration would be that this list represents 
> a qualification of the variable for the specified scope,
> e.g., to indicate that it is in a register.  

Makes sense.

Of course, for this to be valid, we would need to change the spec to remove
this restriction.

> AT_abstract_origin is strictly for function references.  While
> there may be some analogy between inline functions and copies
> of global variables into local registers, I think that the
> relationship is pretty distant.  AT_specification might be
> a closer analogy, although I don't believe that there is
> any need for this either.

It isn't necessary for C, which only has unqualified names.  For C++, you
might refer to the global variable with explicit namespace scope, and you
would want to make that work in the debugger as well.

Using AT_specification seems reasonable to me.

>>>>> "Todd" == Todd Allen <todd.allen@ccur.com> writes:

>    One other thing, though: the local copy must not have a DW_AT_name.
>    If it did, it could interfere with proper visibility code.  The name
>    might even end up creating ambiguities within the local scope.  It
>    isn't a problem in a flat namespace, I suppose.  But it is a problem
>    with hierarchical namespaces.  If you disagree, I'll cope up with some
>    Ada examples.

If the local copy has AT_specification, then it should not have AT_name
anyway.  If it doesn't have AT_specification, it probably should have
AT_name or it would be useless.

[and from another message:]
> Jason: If there is loclist support, could you provide some information on
> where I can find it?  Thanks.

No, GCC doesn't support loclists yet.

Jason


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