This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] New targets remote-rx and extended-remote-rx
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Kevin Buettner <kevinb at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Fri, 30 Apr 2010 23:23:07 +0000 (UTC)
- Subject: Re: [RFC] New targets remote-rx and extended-remote-rx
- References: <20100430144218.182aa18b@redhat.com>
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).
--
Joseph S. Myers
joseph@codesourcery.com