What should be used instead of deprecated_read_memory_nobpt()?
Andrew Cagney
cagney@redhat.com
Wed Dec 7 02:12:00 GMT 2005
Jim here is obviously correct <<there is always a frame>> was intended
as mantra. How would some choose to put it, a simplistic phrase to
capture the imagination of the masses?
There are at least three parts to this:
-- the frame and a relationship to the thread, which in turn has an
address space
-- as DanielJ points to it here:
/*NOTE: drow/2003-09-06: [...]
They should be fixed as above, but meanwhile, we needed a solution for
cases where functions are called with a NULL frame meaning either "the
program is not running" or "use the selected frame". Lazy building of
deprecated_selected_frame confuses the situation, because now
deprecated_selected_frame can be NULL even when the inferior is
running. [...]
...
the need to also handle file-targets where the address space comes from
a file
-- and finally the <<value <has-a> location>>, and that location could,
in turn be a thread's memory, a frame's register, et.al.
It would be good to see these three aspects finally finally pulled
together (works' a killer, sigh).
Andrew
PS: To clarify one thing, value persistance across resumptions of the
inferior is implemented by fetching the value's contents, see
record_latest_value:
<<We don't want this value to have anything to do with the inferior
anymore. In particular, "set $1 = 50" should not affect the variable
from which the value was taken, and fast watchpoints should be able
to assume that a value on the value history never changes.>>
if (value_lazy (val))
value_fetch_lazy (val);
More information about the Gdb
mailing list