From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2881 invoked by alias); 19 Apr 2008 16:40:50 -0000 Received: (qmail 2868 invoked by uid 22791); 19 Apr 2008 16:40:49 -0000 X-Spam-Check-By: sourceware.org Received: from sebabeach.org (HELO sebabeach.org) (64.165.110.50) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 19 Apr 2008 16:40:31 +0000 Received: from seba.sebabeach.org (seba.sebabeach.org [10.8.159.10]) by sebabeach.org (Postfix) with ESMTP id BCEA213EC2 for ; Sat, 19 Apr 2008 09:38:29 -0700 (PDT) Message-ID: <480A2002.9050405@sebabeach.org> Date: Sun, 20 Apr 2008 10:11:00 -0000 From: Doug Evans User-Agent: Thunderbird 2.0.0.12 (X11/20080226) MIME-Version: 1.0 To: gdb@sourceware.org Subject: address space support Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-04/txt/msg00177.txt.bz2 At Transmeta we had a hack to implement address spaces. I.e., CORE_ADDR isn't enough to fully describe all the bits of "memory" one might want to examine. One could do things like "x/x :
". Using that we also hacked in support for x86 segments, so one could do "x/x fs:1234". We didn't want to maintain a ton of local mods so we took a minimalist route. Other ways that have been discussed in the past are things like turning CORE_ADDR into a struct: typedef struct { int address_space ; OLD_CORE_ADDR address; } NEW_CORE_ADDR; or some such (appropriately typed, named, etc.). But that's a ton of work, and not necessarily a maintainable way to go (the common case is addresses are just ints). Hacking CORE_ADDR by putting the address space in the upper bits doesn't necessarily work either. So I don't have a specific proposal, I'm just taking a survey of where things have left off.