dynamic scope from frame, static scope from ???

[Andrew Cagney]

> Andrew Cagney <cagney@gnu.org> writes:
> 
>> GDB's slowly pushing the frame through to the procedures that need
>> access to the dynamic information.  However, I don't know that we've
>> addressed the case where a process needs access to the static
>> information?  Should there be dogma (similar to "there is always a
>> frame") that covers the static case?
>> 
>> Off hand I can think of several ways of doing this:
>> 
>> - create a static-frame (it has no dynamic state) and use that
>> - pass the source-and-line or block where needed
>> functions would get both sal and a possibly null frame
>> - pass some new structure that includes other info such as the
>> selected language (if its different to what it should be)?
> 
> 
> I think the meaning of a static context depends on the language in
> which the user is working.  For C and C++, for example, a static
> context needs to include a specific source line, not just a block, so
> as to be able to find which macros are in scope.

True.  Per: Can't use [some] macro's in conditional breakpoints
http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=856
GDB currently gets this wrong :-(

That rules out block as an option.

> Internally, at least.  As far as the user interface is concerned, GDB
> should try to infer the appropriate language automatically.

Right.  To do that inference correctly the internals need to know the 
users current static context.

The "frame" gives us a path to this information is when the program is 
running.  I'm asking what should should be used to give us that 
information when the program isn't running?

Andrew