Re: Changing "info frame" output?

[Andrew Cagney <cagney@gnu.org>]

Mark Kettenis wrote:
>    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?

Really!

http://sources.redhat.com/gdb/current/onlinedocs/gdb_9.html#SEC65
GDB has four "standard" register names that are available (in 
expressions) on most machines--whenever they do not conflict with an 
architecture's canonical mnemonics for registers. The register names $pc 
and $sp are used for the program counter register and the stack pointer. 
$fp is used for a register that contains a pointer to the current stack 
frame, and $ps is used for a register that contains the processor status.

Core GDB has concepts such as:

- current instruction
- stack inner-most bound
- frame ID (which contains the "frame address")
- frame base et.al.

while an ISA may have related registers:

- program-counter
- frame-pointer
- stack-pointer

A register such as $fp _might_ refer to core GDB's idea of a frame 
address (id.stack_addr) but can equally refer to the ISA's "fp" register 
(see arm where for years we screwed up and printed the wrong "$fp"). 
Similarly for "pc", on VLIW, harvard and delay-slot ISAs, GDB's 
current-instruction while constructed from, is not the same value as $pc.

> While the history of 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.

So what you're proposing is that "info frame" should display the value 
to "pc" and "fp", yet when the user prints $pc and $fp they get 
something entirely different.

We've never resolved the question of what to call the convenience 
variables that correspond to the above core GDB concepts. Sounds like 
its time.

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

I wrote:
 >    Where applicable frame locals and args addresses are also printed.
see the source.

>    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 =".

It could also read "Instruction at".

>    -- /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.

When it comes to scripting, frame ID is a critical part of a users life. 
  Is has to be exposed.  The question is where and how.

>    -- "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.

While core gdb has the concept of the parameter stack's inner-most bound 
(stack used to pass parameters) (a.k.a., stack extent?), used by the 
inferior function call code, it doesn't have a more general concept of 
"sp".  That's ABI / ISA specific (IA-64 has two stacks for instance). 
Perhaphs ISA/ABI should be afforded the oportunity to print ISA/ABI 
specific information, or even provide an abi/isa specific frame-info 
command.

Andrew