What should be used instead of deprecated_read_memory_nobpt()?

What should be used instead of deprecated_read_memory_nobpt()?

[Paul Gilliam]

I need to write an implementation of 'gdbarch_in_function_epilogue_p()'.  In looking for a
model to use, I see that 'hppa_in_function_epilogue_p()' and 's390_in_function_epilogue_p()'
both use 'deprecated_read_memory_nobpt()' to get instructions from the target, but 
'sh_in_function_epilogue_p()' and 'xstormy16_in_function_epilogue_p()' both use
'read_memory_unsigned_integer()' for that purpose.

Can 'read_memory_unsigned_integer()' replace 'deprecated_read_memory_nobpt()'?

-=# Paul #=-

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

[Mark Kettenis]

> From: Paul Gilliam <pgilliam@us.ibm.com>
> Date: Tue, 29 Nov 2005 14:01:30 -0800
> 
> I need to write an implementation of
> 'gdbarch_in_function_epilogue_p()'.  In looking for a model to use,
> I see that 'hppa_in_function_epilogue_p()' and
> 's390_in_function_epilogue_p()' both use
> 'deprecated_read_memory_nobpt()' to get instructions from the
> target, but 'sh_in_function_epilogue_p()' and
> 'xstormy16_in_function_epilogue_p()' both use
> 'read_memory_unsigned_integer()' for that purpose.
> 
> Can 'read_memory_unsigned_integer()' replace 'deprecated_read_memory_nobpt()'?

Not sure, but read_memory_unsigned_integer() might not be safe,
because of the possibility of inserted breakpoints.  The safe
alternative is safe_frame_unwind_memory().  But of course that means
that in_function_epilogue_p should really be changed such that it
accepts a `struct frame *' as an argument.

Mark

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

[Joel Brobecker]

> Not sure, but read_memory_unsigned_integer() might not be safe,
> because of the possibility of inserted breakpoints.

Are there targets that do not remove breakpoints when the target stops?

-- 
Joel

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

[Daniel Jacobowitz]

On Tue, Nov 29, 2005 at 11:04:27PM +0100, Mark Kettenis wrote:
> > From: Paul Gilliam <pgilliam@us.ibm.com>
> > Date: Tue, 29 Nov 2005 14:01:30 -0800
> > 
> > I need to write an implementation of
> > 'gdbarch_in_function_epilogue_p()'.  In looking for a model to use,
> > I see that 'hppa_in_function_epilogue_p()' and
> > 's390_in_function_epilogue_p()' both use
> > 'deprecated_read_memory_nobpt()' to get instructions from the
> > target, but 'sh_in_function_epilogue_p()' and
> > 'xstormy16_in_function_epilogue_p()' both use
> > 'read_memory_unsigned_integer()' for that purpose.
> > 
> > Can 'read_memory_unsigned_integer()' replace 'deprecated_read_memory_nobpt()'?
> 
> Not sure, but read_memory_unsigned_integer() might not be safe,
> because of the possibility of inserted breakpoints.  The safe
> alternative is safe_frame_unwind_memory().  But of course that means
> that in_function_epilogue_p should really be changed such that it
> accepts a `struct frame *' as an argument.

Which would be a good change if we really need this method anyway.
I'm dubious how much good it does...

-- 
Daniel Jacobowitz
CodeSourcery, LLC

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

[Daniel Jacobowitz]

On Tue, Nov 29, 2005 at 02:07:52PM -0800, Joel Brobecker wrote:
> > Not sure, but read_memory_unsigned_integer() might not be safe,
> > because of the possibility of inserted breakpoints.
> 
> Are there targets that do not remove breakpoints when the target stops?

No, this is target independent.  But someday I hope that GDB will not
require this.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

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

[Jim Blandy]

Some background:

The long-term plan here was to have GDB pass frame objects around
everywhere, and always fetch registers and memory relative to a
specific frame.  It's pretty obvious why you need to have a frame to
find a register value, but why you'd want to read memory "from a
frame" is less so.

The idea was to use frames to reduce GDB's dependence on global state:
- A frame has a specific architecture.
- A frame belongs to a specific thread.
- Since threads belong to specific processes, a frame belongs to a
specific process, too, which would help with debugging multi-address
space programs.

So if you have a frame around to provide context for whatever you're
trying to do, you don't have to depend on a global arch object, a
global current thread, a global process, and so on.

This was Andrew Cagney's initiative, but he's not active on GDB any
more, which is why I say "the idea was to..."  I think it's a good
approach, as far as it goes, and I hope we carry it on.  We should use
the frame-based register and memory operations whenever possible;
where you don't have a frame, try to figure out how to propage an
appropriate frame out to where it's needed; go ahead and add 'frame'
parameters to functions where it makes sense.

There are some cases where it doesn't make sense.  For example, our
'struct value' objects read memory lazily, so if you were going to use
frames for everything, you'd need to have the value point to the frame
GDB should use to read the value's contents when they're actually
needed.  But values persist across continues and steps, whereas frame
objects are destroyed and rebuilt each time the inferior runs.  So
values can't just point to frames.  Frame ID's are more persistent,
but they're still not right, because the frame might really be popped
in the inferior.

I think this shows that, to really acheive the dream, we also need an
object representing an address space.  Memory reads and writes would
accept an address space argument.  A thread would have a (current?)
address space, and thus a "frame's address space" would be the
"frame's thread's address space".  values would contain an address
space to use to fetch their values when needed.

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

[Paul Gilliam]

Way Cool.

Thanks for the background.   Maybe someone can pick up the tourch for this.

I wonder how this fits in with Michael Snyder's multi-process gdb?
http://sourceware.org/ml/gdb-patches/2005-11/msg00490.html

-=# Paul #=-


On Tuesday 29 November 2005 17:36, Jim Blandy wrote:
> Some background:
> 
> The long-term plan here was to have GDB pass frame objects around
> everywhere, and always fetch registers and memory relative to a
> specific frame.  It's pretty obvious why you need to have a frame to
> find a register value, but why you'd want to read memory "from a
> frame" is less so.
> 
> The idea was to use frames to reduce GDB's dependence on global state:
> - A frame has a specific architecture.
> - A frame belongs to a specific thread.
> - Since threads belong to specific processes, a frame belongs to a
> specific process, too, which would help with debugging multi-address
> space programs.
> 
> So if you have a frame around to provide context for whatever you're
> trying to do, you don't have to depend on a global arch object, a
> global current thread, a global process, and so on.
> 
> This was Andrew Cagney's initiative, but he's not active on GDB any
> more, which is why I say "the idea was to..."  I think it's a good
> approach, as far as it goes, and I hope we carry it on.  We should use
> the frame-based register and memory operations whenever possible;
> where you don't have a frame, try to figure out how to propage an
> appropriate frame out to where it's needed; go ahead and add 'frame'
> parameters to functions where it makes sense.
> 
> There are some cases where it doesn't make sense.  For example, our
> 'struct value' objects read memory lazily, so if you were going to use
> frames for everything, you'd need to have the value point to the frame
> GDB should use to read the value's contents when they're actually
> needed.  But values persist across continues and steps, whereas frame
> objects are destroyed and rebuilt each time the inferior runs.  So
> values can't just point to frames.  Frame ID's are more persistent,
> but they're still not right, because the frame might really be popped
> in the inferior.
> 
> I think this shows that, to really acheive the dream, we also need an
> object representing an address space.  Memory reads and writes would
> accept an address space argument.  A thread would have a (current?)
> address space, and thus a "frame's address space" would be the
> "frame's thread's address space".  values would contain an address
> space to use to fetch their values when needed.
> 
> 

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

[Andrew Cagney]

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