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

[Pedro Alves <pedro@codesourcery.com>]

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

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

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

-- 
Pedro Alves