This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Changing "info frame" output?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]