This is the mail archive of the
mailing list for the GDB project.
Re: What should be used instead of deprecated_read_memory_nobpt()?
- From: Andrew Cagney <cagney at redhat dot com>
- To: pgilliam at us dot ibm dot com
- Cc: Jim Blandy <jimb at redhat dot com>, gdb at sources dot redhat dot com
- Date: Tue, 06 Dec 2005 21:08:52 -0500
- Subject: Re: What should be used instead of deprecated_read_memory_nobpt()?
- References: <firstname.lastname@example.org> <20051129221457.GB2238@nevyn.them.org> <email@example.com> <firstname.lastname@example.org>
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
-- 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
the need to also handle file-targets where the address space comes from
-- 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).
PS: To clarify one thing, value persistance across resumptions of the
inferior is implemented by fetching the value's contents, see
<<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))