Mirror of the gdb mailing list
 help / color / mirror / Atom feed
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.




             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