Re: dynamic scope from frame, static scope from ???

[Andrew Cagney <cagney at gnu dot org>]

> 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