From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 693 invoked by alias); 30 Apr 2010 23:23:15 -0000 Received: (qmail 684 invoked by uid 22791); 30 Apr 2010 23:23:14 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 30 Apr 2010 23:23:10 +0000 Received: (qmail 31323 invoked from network); 30 Apr 2010 23:23:08 -0000 Received: from unknown (HELO digraph.polyomino.org.uk) (joseph@127.0.0.2) by mail.codesourcery.com with ESMTPA; 30 Apr 2010 23:23:08 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.69) (envelope-from ) id 1O7zY3-0000Yy-CT; Fri, 30 Apr 2010 23:23:07 +0000 Date: Fri, 30 Apr 2010 23:23:00 -0000 From: "Joseph S. Myers" To: Kevin Buettner cc: gdb-patches@sourceware.org Subject: Re: [RFC] New targets remote-rx and extended-remote-rx In-Reply-To: <20100430144218.182aa18b@redhat.com> Message-ID: References: <20100430144218.182aa18b@redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-04/txt/msg01025.txt.bz2 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