From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15998 invoked by alias); 3 May 2010 23:18:52 -0000 Received: (qmail 15985 invoked by uid 22791); 3 May 2010 23:18:51 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 03 May 2010 23:18:45 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o43NIijs030308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 3 May 2010 19:18:44 -0400 Received: from localhost.localdomain (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o43NIg7Q010027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 3 May 2010 19:18:43 -0400 Date: Mon, 03 May 2010 23:18:00 -0000 From: Kevin Buettner To: gdb-patches@sourceware.org Subject: Re: [RFC] New targets remote-rx and extended-remote-rx Message-ID: <20100503161842.52fb4243@redhat.com> In-Reply-To: References: <20100430144218.182aa18b@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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-05/txt/msg00059.txt.bz2 On Fri, 30 Apr 2010 23:23:07 +0000 (UTC) "Joseph S. Myers" 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