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

[Kevin Buettner <kevinb@redhat.com>]

On Fri, 30 Apr 2010 23:35:44 +0100
Pedro Alves <pedro@codesourcery.com> wrote:

> On Friday 30 April 2010 22:42:18, Kevin Buettner wrote:
> > The patch below adds two new targets, remote-rx and
> > extended-remote-rx, which provide a serial debug interface to
> > platforms using the Renesas RX architecture.  The interface is
> > identical to that defined by remote.c except that memory transfer
> > operations are redefined to do byte swapping under certain conditions.
> > 
> > The new file, remote-rx.c, inherits operations defined in remote.c. 
> > It overrides several of those operations in order to provide support
> > for some of the idiosyncracies of the RX architecture.  The long comment
> > near the beginning of remote-rx.c explains the motivation for this
> > patch and these new targets.
> 
> I'm not convinced this inheritance is a good idea.  Why not
> handle this in the regular remote target instead?

I didn't want to complicate remote.c (or other parts of GDB) with code
which would be used for very few (possibly only one) target(s). 
However, Joseph's reply suggests that RX's idiosyncracies may not be
as uncommon as I first thought.  I'm willing to consider other
approaches to solving this problem.

> Adding new
> targets is evil.  :-)  That is, say, with a gdbarch flag telling
> the remote.c target to handle this when needed.  (or a
> qSupported feature, or  a new feature in the xml target
> description if it is expected that stubs might handle this
> themselves somehow)
> 
> This would remove the burden from the user/frontend, of
> knowing upfront the idiosyncracies of this architecture,
> and having to remember to connect with a special target.

This is a good point.  For RX, if the user were to use "target remote"
instead of "target remote-rx", things will definitely not work.

> Or, even, imagine that at some point you will have a native
> gdb running on such architecture.  This raises the question of
> whether it would make more sense to make the common memory reading
> code handle this independent of target_ops instead.  On first
> sight, it seems to.

Yes, this might make sense.  (Though, at present, the RX sim has
memory swapping code on the sim side of things.  But it'll be easy to
remove the swapping code from the sim.  And it would make sense to
have it done in one place in GDB.)

I'll start poking around in the common memory reading code.  (I
did take a quick look before starting remote-rx.c.  It turned
out to be a bit more complicated than I expected it to be.)

> 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_CODE?  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.

> Lastly, is there any relation between the new address_range
> structure, and struct addrmap?

I probably could have used struct addrmap instead of introducing a new
data structure.

Kevin