Re: [RFC] New targets remote-rx and extended-remote-rx

[Pedro Alves <pedro@codesourcery.com>]

On Monday 03 May 2010 23:30:29, Kevin Buettner wrote:
> On Fri, 30 Apr 2010 23:35:44 +0100
> Pedro Alves <pedro@codesourcery.com> wrote:

> > I'm not sure I grasped it enough to understand
> > if this could benefit from a TARGET_OBJECT_MEMORY_CODE vs
> > TARGET_OBJECT_MEMORY_DATA request distinction, instead of just
> > calling everything TARGET_OBJECT_MEMORY?  That is switch
> > the swapping decision to the transfer intent, not to where
> > the code is in memory.
> 
> I'll have to think about this.  Doesn't sound unreasonable though.
> 
> > For example, what should happen
> > if I build a buffer of executable code in memory at runtime,
> > and I want to disassemble it with GDB?  I'll build the memory
> > buffer, with a layout as the compiler puts things in .text,
> > but the code will not be in .text, yet, don't I want for
> > GDB to read it in execute order, not memory order?
> 
> E.g, a just-in-time (JIT) compiler?  Yes, you'd want GDB to convert
> dynamically compiled code from memory order to execute order.

Yes, that's one example, although there are many more use cases
beyond a full fledged compiler.  Just staying in gdb land, think of
things like debugging the displaced stepping scratch pad (when you
add support for non-stop mode you'll want to debug this, probably).
Another example, debugging fast tracepoints support for RX.  In the latter,
we patch the code stream with a jump into small trampoline routine built
at runtime in the inferior's memory.  Just copying a piece of .text
code into a data buffer, and trying to disassemble it is another example.

The more I think of this, the more it seems that it's the thought/intent
that counts.

-- 
Pedro Alves