dynamic scope from frame, static scope from ???

dynamic scope from frame, static scope from ???

[Andrew Cagney]

Hello,

(had an interesting hallway conversation)

The languages that GDB debugs, being good old fashoned procedural, have 
both a static (compile time) and dynamic (run time) [scope] information. 
  Static information includes things like the current language, source 
line, and the names of variables that are in scope.  The dynamic 
information includes things like the call chain and the actual location 
(instance) of a variable.

Given a live process (or core file), the frame provides access to the 
dynamic info, and via the frame's PC, the static information.

Conversely, when there is no program.  GDB has the current 
source-and-line and that can be used to determine static program 
information.  For instance, the break command refers to static 
information when setting a breakpoint.

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)?

thoughts?
Andrew

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

[Jim Blandy]

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.

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

Re: 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

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

[Jim Blandy]

Andrew Cagney <cagney@gnu.org> writes:
> 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 :-(

Yep.  parse_exp_1 should take a sal, not a block, and
expression_context_pc should have been expression_context_sal.  (I've
added a note to the PR.)

> 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?

Actually, now that I look at it, what's wrong with 'struct
symtab_and_line' for a static context?  You can get a block from that
with block_for_pc_sect (sal.pc, sal.section).  (There should be a
function, block_for_sal, which does that.)