From: Paul Schlie <schlie@comcast.net>
To: <gdb@sources.redhat.com>
Subject: Re: Changing "info frame" output?
Date: Fri, 05 Nov 2004 07:28:00 -0000 [thread overview]
Message-ID: <BDB095C2.7C76%schlie@comcast.net> (raw)
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.
next reply other threads:[~2004-11-05 7:28 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-05 7:28 Paul Schlie [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-11-03 20:49 Nick Roberts
2004-11-05 15:00 ` Andrew Cagney
2004-11-03 16:28 Andrew Cagney
2004-11-04 21:59 ` Mark Kettenis
2004-11-05 14:53 ` Andrew Cagney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BDB095C2.7C76%schlie@comcast.net \
--to=schlie@comcast.net \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox