Changing "info frame" output?
Paul Schlie
schlie@comcast.net
Fri Nov 5 07:28:00 GMT 2004
Although possibly too radical a departure, might something like this
be worthy of consideration:
frame: NN, pc: 0x12345678, sr: 0x12345678
line: 442, file: /file_path/.../file_name
source: int function_name(int alpha, int beta);
global: 'zeta=>r5, <return_value>=>r0, sp=>fp
caller: 'alpha=>r1, 'beta=>r2, pc=>(sp+0), sr=>(sp+4)
-saved: r3>r12, r4=>sp+4, r5=>(sp+8)
-local: 'n=>r3, 'o=>r4, <t1>=>r5, <t2>=>r6
Where on a frame by frame basis one can easily see the current state
of program execution simultaneously with the symbolic variable, and
saved register mappings associated with the corresponding call frame;
and independently view their values as desired using print expressions.
Such that if one wanted to see the previously saved pc (i.e. return
address), one could simply print the memory location ($sp+0), as
identified in the frame caller register mapping as having been the
store location of the previous pc. Where hypothetically:
global: lists the logical variable and register mapping established
within earlier frames, but inherited by the called frame.
caller: lists the logical variables and program state passed to the
frame.
-saved: lists the registers that were saved to either other registers
or off to the stack prior to being logically allocated for
local use (and reversed prior to return).
-local: lists the logical variable register and/or memory mappings
local to the current frame.
(where for the sake of argument I've used 'name to quote symbolic
names, and used <name> to designate implied logical variable names)
Although there are many ways to skin this cat, it just stuck me as a
potentially simple and succinct way to provide at a glance most of the
information most significant to the debugging process; and does so in a
reasonably flexible way that allows logical variables and/or previous
register values to be easily shown as being mapped to either registers,
or register indirect to memory on a frame by frame basis, therefore
friendly to a variety of CPU architectures, etc.
More information about the Gdb
mailing list