From: Andrew Cagney <ac131313@redhat.com>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: gdb@sources.redhat.com
Subject: Re: Failures in store.exp caused by regcache
Date: Thu, 09 Jan 2003 16:50:00 -0000 [thread overview]
Message-ID: <3E1DA834.5060906@redhat.com> (raw)
In-Reply-To: <20030109032346.GA10532@nevyn.them.org>
> 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.
It isn't that bad. In fact (per previous discussion), the code needed
to avoid flushing the caches would be far worse than what we have now.
The only time the frame cache gets (well, ok, should get ...) flushed is:
- when the target resumes
The recovery time here is critical.
- when the target is modified
The recovery time here is bounded by the recovery time from a target resume.
People `never' modify the target. That leaves the time taken to recover
from a resume and then:
- we must flush the cache
- since it is an upper bound on target modify recovery time, making it
faster is a win win.
> We obviously want to preserve things like the selected frame, however.
I'm actually a bit puzzled. I recently fixed a case and added a
testcase (store.exp) that handles stores. Look for frame_find_by_id()
in valops.c.
> 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.:
Have a look at the comments in "frame.h" around reinit_frame_cache() and
get_selected_frame(). In particular:
FIXME: cagney/2002-11-28: The only difference between
flush_cached_frames() and reinit_frame_cache() is that the latter
explicitly sets the selected frame back to the current frame there
isn't any real difference (except that one delays the selection of
a new frame). Code can instead simply rely on get_selected_frame()
to reinit's the selected frame as needed. As for invalidating the
cache, there should be two methods one that reverts the thread's
selected frame back to current frame (for when the inferior
resumes) and one that does not (for when the user modifies the
target invalidating the frame cache). */
/* FIXME: cagney/2002-11-28: At present, when there is no selected
frame, this function always returns the current (inner most) frame.
It should instead, when a thread has previously had its frame
selected (but not resumed) and the frame cache invalidated, find
and then return that thread's previously selected frame. */
This only works if we're storing the selected frame in the selected
thread. Unfortunatly (arrrrrrg), GDB first needs to be convinced that
`there is always a thread' so that there is always a `struct
thread_info' into which the selected frame's id can be stored (or, I
guess, as a temp, extend the existing `there might be a thread' hack to
handle this case, double arrrrg).
The below does raise an interesting question:
> 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);
> }
what should:
(gdb) set backtrace-below-main on
(gdb) up ; up ; up
(gdb) set backtrace-below-main off
(gdb) set variable x = 1
do? get_next_frame() is going to refuse to go beyond main, no matter
how many times you try.
(btw, a frame_id is safer than a level).
Andrew
next prev parent reply other threads:[~2003-01-09 16:50 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
2003-01-09 16:50 ` Andrew Cagney [this message]
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=3E1DA834.5060906@redhat.com \
--to=ac131313@redhat.com \
--cc=drow@mvista.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