This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Fri, 30 Apr 2010 23:23:07 +0000 (UTC)
"Joseph S. Myers" <joseph@codesourcery.com> wrote:

> On Fri, 30 Apr 2010, Kevin Buettner wrote:
> 
> > +   Within an executable file, words in code sections are stored in
> > +   in `memory order'.  Thus words in an executable file could be
> > +   directly transferred to an RX target's memory without requiring
> > +   any swapping.  `Memory order', however, is often not the most
> > +   natural order for the rest of the toolchain to operate on the
> > +   instructions.  E.g, when disassembling a sequence of instructions,
> > +   the disassembler will want to look at the instruction bytes in the
> > +   same order as that with which the execution unit of the chip sees
> > +   them, i.e, it'll want to look at them in `execution unit order'.
> 
> The issue of having memory order different from execution unit order is 
> not unique to the RX, so one question would be what is the right general 
> approach to handle such issues for other targets as well.
> 
> The case I know of is the TI C6X processors (C64X+ and C674X are the only 
> ones affected by this issue).  The C64X+ and C674X have a compact 
> instruction encoding where some instructions are 16 bits and some are 
> 32 bits; 256-bit fetch packets can have a header saying which 32-bit words 
> are a single instruction and which are two 16-bit instructions.  In 
> execution unit order, the least significant half of a pair of 16-bit 
> instructions always comes before the most significant half, leading to 
> them being out of order in memory order in the big-endian case.
> 
> On this processor, branch instructions work with logical addresses, where 
> a 4-byte-aligned address pointing to a pair of 16-bit instructions always 
> refers to the least-significant - first in execution unit order - of those 
> instructions, rather than with physical addresses.  External code symbols 
> are required to be 4-byte-aligned (most branch instructions only support 
> 4-byte-aligned target addresses).  (The ISA manuals don't make this clear, 
> but it's been confirmed with TI that this is how the processors work and 
> what the ABI should be.)
> 
> We haven't yet started the GDB port or the assembler support for 16-bit 
> instructions, but for the disassembler the approach we've followed (see 
> opcodes/tic6x-dis.c, which can handle 16-bit instructions to the extent of 
> knowing what's 32-bit and what's 16-bit although they aren't yet in the 
> opcode table), which is also the approach followed by TI's tools, is that 
> when asked to disassemble the instruction at a given address it treats it 
> as a logical rather than a physical address.  So BFD doesn't need to do 
> anything special regarding this peculiarity, but the assembler will need 
> to swap instructions at the last minute when it gets support for 16-bit 
> instructions, and of course there may be GDB issues such as you found (but 
> possibly a different set of issues because of not making BFD do the 
> swapping).

For RX, I have mixed feelings about having BFD do the swapping.  On
the one hand, it makes coding certain parts of the toolchain easier. 
But, on the other hand, it introduces the need to do memory-order-to-
execute-order swapping when reading memory from a target.  (And vice
versa, when writing.) But then I remind myself that any instruction
decoding code will have to perform this swapping instead, which then
makes me think that the swapping in BFD isn't so bad after all.  And,
in addition, non-aligned code addresses generally refer to execute
order, rather than memory order.  I honestly don't know what the
"right" way to do it should be.

Kevin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]