[RFC] New targets remote-rx and extended-remote-rx
Pedro Alves
pedro@codesourcery.com
Fri Apr 30 22:35:00 GMT 2010
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
More information about the Gdb-patches
mailing list