From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17062 invoked by alias); 21 Apr 2008 12:57:58 -0000 Received: (qmail 17053 invoked by uid 22791); 21 Apr 2008 12:57:57 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate4.de.ibm.com (HELO mtagate4.de.ibm.com) (195.212.29.153) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 21 Apr 2008 12:57:36 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.13.8/8.13.8) with ESMTP id m3LCvXgh108732 for ; Mon, 21 Apr 2008 12:57:33 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m3LCvXiw3932222 for ; Mon, 21 Apr 2008 14:57:33 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m3LCvWUd000509 for ; Mon, 21 Apr 2008 14:57:32 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id m3LCvWjT000506; Mon, 21 Apr 2008 14:57:32 +0200 Message-Id: <200804211257.m3LCvWjT000506@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Mon, 21 Apr 2008 14:57:32 +0200 Subject: Re: address space support To: dje@sebabeach.org (Doug Evans) Date: Mon, 21 Apr 2008 17:57:00 -0000 From: "Ulrich Weigand" Cc: gdb@sourceware.org In-Reply-To: <480A2002.9050405@sebabeach.org> from "Doug Evans" at Apr 19, 2008 09:38:26 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00183.txt.bz2 Doug Evans wrote: > 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. My current out-of-tree patch to support combined PPU/SPU debugging on the Cell/B.E. does use the latter method (encode address space into the upper bits of CORE_ADDR). I'd certainly prefer to see a more generic method supported by core GDB as well ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com