This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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,

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]