Re: variables in scopes

[Roland McGrath <roland at redhat dot com>]

I think I failed to communicate my fundamental point.

There are two "frame"s or "scope"s here.  One is the stack/register context
from which locals need to be accessed, which is directly associated with a
PC value.  The other is the lexical scope context from which names should
be associated with variable DIEs.  That scope can be identified in a
variety of ways.  

It's given that the user has already identified the frame context from
which lookups will be done.  That is, they've identified a PC location.

For a given PC, there is a lexical scope that corresponds to the source
location of that PC, which is the one usually referred to.  You were
talking about identify other scopes relative to that one by moving outward
a counted number of containing scopes.

I think a user wants to be able to identify particular containing scopes in
a variety of ways, such as function names or source locations.  These need
to be reduced to a single PC location that identifies the right lexical
scope (i.e. the correct particular inline instantiation or whatever).  A
user would like to just indicate a source location and have it do the right
thing.  A source location yields many PC locations, not one.  What the user
wants is to give a source location and variable name, and have something
figure out which incarnation of that source location they really meant.
So, requiring the user to give a PC location indicating the particular
lexical scope is too inconvenient.  Instead, provide a way to give a
specification (like source location) that results in many candidate PCs,
and then select the one that actually lies in a containing scope of the
frame context already identified by its PC.