Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Mo DeJong <supermo@bayarea.net>
To: gdb@sources.redhat.com
Subject: Re: Proposed mod for stack-select-frame MI command
Date: Thu, 01 Aug 2002 19:18:00 -0000	[thread overview]
Message-ID: <20020801191811.4144cc0c.supermo@bayarea.net> (raw)
In-Reply-To: <3D49C36A.9060504@ges.redhat.com>

On Thu, 01 Aug 2002 19:25:30 -0400
Andrew Cagney <ac131313@ges.redhat.com> wrote:

> Mo, is this needed or is it just a convenience?  Won't the client need 
> to track the current stack level and hence can simply adjust/use that 
> local copy.

I am not sure what the possible complications of that approach might
be. You could assume that the stack level was reset to 0 when a
breakpoint was hit and then increment and decrement it. I am
not sure what would happen if you started calling inferior functions
though. I have seen gdb do things like switch back to the innermost
frame after calling an inferior function at some other level of the
stack. If that happened, the client would think the stack was one
value while gdb could think it was another. I would rather just
keep all that info in gdb.

You would also need to assume that the client would not use the
frame, up, down and other cli methods via the MI. If they did, the
local stack level integer that the client held would be wrong.

This just seems like something that should be easy to do via the
MI. It is just a way to access up or down like functionality.
If you check the existing docs for the -stack-select-frame, it
states that up, down, up-silent, and down-silent commands
map the -stack-select-frame. My take on the change is that it
gets the implementation in line with the documentation.
So to sum up, I think it is needed.

cheers
Mo


  reply	other threads:[~2002-08-02  2:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-25 20:21 Mo DeJong
2002-08-01 16:25 ` Andrew Cagney
2002-08-01 19:18   ` Mo DeJong [this message]
2002-08-01 21:03     ` Keith Seitz
2002-08-02  6:28     ` Elena Zannoni

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=20020801191811.4144cc0c.supermo@bayarea.net \
    --to=supermo@bayarea.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