rfc/wip $gdbframe

[Andrew Cagney]

Hello,

Ref:
http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=327
http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=251

The attached patch is work in progress on ``The $fp problem''.

It creates a new register $gdbframe that sits above the range of target 
registers [0 .. NUM_REGS+NUM_PSEUDO_REGS).  This register than contains 
the frame.base.  While the basic mechanism appears to be working, this 
change does raise a few interesting questions.

--

The name: $fp, $frame, $gdbframe, $gdb.frame, $gdb_frame

Some targets have a real $fp.  Since the real $fp takes precidence, such 
targets wouldn't have access to the builtin register.  $frame is likely 
similar (true?).  Hence a $gdb prefix is included.

I have a preference for $gdbframe over $gdb_frame as it uses less shift 
keys (I can be convinced of otherwize :-).

$gdb.frame would be good.  That way everything is in a single variable. 
  It has other issues (below) though.

--

Target access?

At present $gdbframe makes use of information found in 
``selected_frame''.  Since that information is local to GDB, a reference 
to $frame doesn't involve additional querying of the target (it is cheap).

$gdbframe could, however, be extended to display things like the values 
of saved registers and the like.  Since that would require accessing 
target info it would be more expensive.

My feeling is that, as a policy, $gdbframe should not introduce 
additional target accesses keeping it light weight.

--

$gdb.frame, $gdb.locals, $gdb.... VS $gdbframe, $gdblocals, ...

An idea is to have $gdb have multiple fields: $gdb.frame $gdb.locals 
$gdb... While it looks good, I suspect it might suffer from the same 
problems as ``target access'' above.

The $gdb variable would need to be completly initialized in a single 
hit.  By having separate variables, they can each have their own policy 
- $gdblocals might be expensive but $gdbframe is cheap.

If someone knows how to do this without the need to initialize all 
fields, I'm all ears!

--

Thoughts?

Andrew






The gdb prefix is to, hopefully, stop any conflicts with existing variables.
I have a dislike of the shift key so prefer $gdbframe over $gdb_frame 
(but I can be convinced otherwise :-).

--

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diffs
URL: <http://sourceware.org/pipermail/gdb/attachments/20020209/a1dfdeef/attachment.ksh>