From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9447 invoked by alias); 5 Feb 2002 14:22:44 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 9309 invoked from network); 5 Feb 2002 14:22:41 -0000 Received: from unknown (HELO mail00.oculustech.com) (64.221.47.99) by sources.redhat.com with SMTP; 5 Feb 2002 14:22:41 -0000 Received: from oculustech.com (dsl-64-192-85-73.telocity.com [64.192.85.73]) by mail00.oculustech.com (Postfix) with ESMTP id CEA4F1151 for ; Tue, 5 Feb 2002 09:22:37 -0500 (EST) Message-ID: <3C5FEAA4.4E46F7C9@oculustech.com> Date: Tue, 05 Feb 2002 06:22:00 -0000 From: Timothy Wall Reply-To: twall@oculustech.com Organization: Oculus Technologies X-Mailer: Mozilla 4.74 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: gdb@sources.redhat.com Subject: Address generation question Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit X-SW-Source: 2002-02/txt/msg00100.txt.bz2 I'm working on support for a DSP that has a dual addressing architecture (actually quite common in DSPs). That in itself is not too big a problem, since GDB's CORE_ADDR can be made sufficiently large to include flags to indicate a particulare address bus. The issue I'm working on is that one bus addresses by octet, while another addresses by 16-bit word. When generating a new address from a base and an octet count, 0x1000 + 2 octets in the first case results in 0x1002, while in the second it results in 0x1001. (At one time it was suggested to represent the second address as 0x2002, effectively directly mapping all octets, but while this makes easy integration into GDB, it's really ugly to use in practice, requiring the programmer to translate the addresses back to what they "really" are). I'd like to know if anyone knows of any structures already built into GDB that might be suited to handling this arrangement. I haven't found any, so I figured I'd simply build on some previous DSP work I've done which allows GDB to handle architectures with non-octet bytes (i.e., the least addressible unit on the target system is something other than 8 bits). My proposed solution is to encapsulate the address generation bits into a macro, ADDR_OFFSET(a,b), where 'a' is the starting CORE_ADDR and 'b' is the octet offset count. The result of this macro is assigned to the new address. This makes it relatively easy to generate an offset appropriate to the addressing bus represenged in 'a'. I'm not sure yet if there are places where intermediate values need to be saved which might lose the initial address context, though. Thanks for any input T.