Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@mvista.com>
To: Andrew Cagney <ac131313@redhat.com>
Cc: gdb@sources.redhat.com
Subject: Re: Failures in store.exp caused by regcache
Date: Thu, 09 Jan 2003 03:23:00 -0000	[thread overview]
Message-ID: <20030109032346.GA10532@nevyn.them.org> (raw)
In-Reply-To: <3E1C77B4.8070401@redhat.com>

On Wed, Jan 08, 2003 at 02:10:44PM -0500, Andrew Cagney wrote:
> >(Or rather, by the value code's interaction with the regcache)
> >
> >Andrew, this is more your area; I'd like your advice before I dig any
> >further.  Here's what's going wrong.  Consider the command sequence:
> >"up; print u; set u = s_1; print u".
> >  - u has class LOC_REGISTER
> >  - The register's home is memory
> >  - read_var_value therefore returns an lval_memory
> >  - the value of the register is in the register unwind cache at this point
> >  - we modify the memory backing the store
> >  - we have no way to tell that we've just modified the value of a saved
> >    register on the stack
> >  - the second print returns the cached value
> >
> >So, what do we do?
> 
> Flush the frame cache.

Ugg.  Well, if we have to, then we have to.  I suppose we do.

We obviously want to preserve things like the selected frame, however. 
Andrew, should I do this the way I do for "set backtrace-below-main",
and should there be a general function for that?  I.E.:

void
do_flush_frames_sfunc (char *args, int from_tty, struct cmd_list_element *c)
{
  int saved_level;
  struct frame_info *cur_frame;

  if (! target_has_stack)
    return;

  saved_level = frame_relative_level (get_selected_frame ());

  flush_cached_frames ();

  cur_frame = find_relative_frame (get_current_frame (), &saved_level);
  select_frame (cur_frame);

  /* If we were below main and backtrace-below-main was turned off,
     SAVED_LEVEL will be non-zero.  CUR_FRAME will point to main.
     Accept this but print the new frame.  */
  if (saved_level != 0)
    print_stack_frame (get_selected_frame (), -1, 0);
}


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


  reply	other threads:[~2003-01-09  3:23 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-08 19:05 Daniel Jacobowitz
2003-01-08 19:11 ` Andrew Cagney
2003-01-09  3:23   ` Daniel Jacobowitz [this message]
2003-01-09 16:50     ` Andrew Cagney
2003-01-09 17:14       ` Daniel Jacobowitz
2003-01-09 17:48         ` 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=20030109032346.GA10532@nevyn.them.org \
    --to=drow@mvista.com \
    --cc=ac131313@redhat.com \
    --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