Re: What should be used instead of deprecated_read_memory_nobpt()?

[Andrew Cagney <cagney at redhat dot com>]

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);