Re: Changing "info frame" output?

[Mark Kettenis <kettenis at gnu dot org>]

   Date: Wed, 03 Nov 2004 11:27:50 -0500
   From: Andrew Cagney <cagney@gnu.org>

   Hello,

   GDB's current info frame output looks like:

   Stack level 1, frame at 0x7ffff290:
     pc = 0x1005e5f8 in fprintf_filtered 
   (/home/scratch/GDB/src/gdb/utils.c:2231);
	saved pc 0x1005a6b8
     called by frame at 0x7ffff2b0, caller of frame at 0x7ffff210
     source language c.
     Arglist at 0x7ffff210, args: stream=0x10465888,
	format=0x1036fe4c "GNU gdb %s\n"
     Locals at 0x7ffff210, Previous frame's sp is 0x7ffff290
     Saved registers:
      pc at 0x7ffff294, lr at 0x7ffff294

   I see several problems (some apparent, some not so):

   - PC and SP as registers really no longer apply.
   Phrases such as ``pc = ...'' and ``saved pc'', and ``Previous frame's 
   SP'' should be worded in a more ISA netural way.

Really?  While the history of pc, sp, fp and ps is defenitely related
to commonly used aliases for certain PDP11 registers, I really see
them as abstract registers.  The program counter or instruction
pointer is a fundamental feature of the von Neumann architecture.  All
the ISA's that I know of, have the concept of a stack pointer,
although in many of them the register used as a stack pointer is only
a software convention.  The concept of a frame pointer is absent in
many modern ISA's, although some of them speak of a "virtual" frame
pointer.  Most ISA's have somes sort of processor status register.

So I see the names pc, sp, fp and ps as abbreviations for the concepts
I mention above.  As such I see no problem in using them in the "frame
info" output.

   - Often there isn't an "Arglist at ..."
   Modern architectures often don't push any arguments on the stack so the 
   argument address isn't meaningful.

All the world's a VAX...  However, Arglist... and Locals... are
relevant for various kinds of debug info, so we should retain the
possibility to print them.

   - More register info.
   Modern ISAs also save registers in other registers, that should be 
   displayed.  That its talking about registers saved by this frame should 
   be clarified.

Agreed.

   and with that in mind have come up with the following as a draft:

   Stack level 1, frame at 0x7ffff240:
     Code at 0x1005e5f8 in fprintf_filtered (stream=0x10467888,
	format=0x10371b74 "GNU gdb %s\n")
	at /home/scratch/PENDING/2004-10-29-full-location/src/gdb/utils.c:2231
     called by frame at 0x7ffff260, caller of frame at 0x7ffff1c0
     Source language c.
     Frame base at 0x7ffff1c0.
     Registers saved by this frame:
	pc at 0x7ffff244, lr at 0x7ffff244

   Notice how:

   -- source location (second line) uses a more "standard" format
   The one printed when switching frames using up/down.  The format 
   includes the argment list.  I've also modified it to print "Code at" 
   instead of "pc =".

I think replacing "pc =" with "Code at" isn't an improvement for the
reason given above.

   -- the separate ``Arglist at ...'' line is dropped
   The actual list is moved to "source location"; while the args address is 
   moved to ...

   -- a new "Frame base" line
   Where applicable frame locals and args addresses are also printed.

What do you mean with "Where applicable?".

   -- /Saved registers:/Registered saved by this frame/
   And the list can include registers saved in another register (but the 
   example doesn't show this).

   I'm still wondering:

   -- Frame's ID?
   Should this be printed - the frame address is the frame ID's address 
   already.

I don't think so.  The frame ID is an internal GDB concept that we
shouldn't expose to the user.  But we should print enough information
with "info frame" for the user to distinguish between frames.

   -- "saved pc" dropped
   Perhaphs it should print "Return address ..."?

I like "Return address".  It's a general concept that doesn't contain
the misleading "saved".

Your proposal no longer prints the "Previous frame's sp".  I think
this leaves out important information.

Mark