From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21385 invoked by alias); 5 Oct 2006 22:26:57 -0000 Received: (qmail 21377 invoked by uid 22791); 5 Oct 2006 22:26:57 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Thu, 05 Oct 2006 22:26:52 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1GVbg1-00045m-QW for gdb-patches@sourceware.org; Thu, 05 Oct 2006 18:26:49 -0400 Date: Thu, 05 Oct 2006 22:26:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sourceware.org Subject: Re: [patch] Cut memory address width Message-ID: <20061005222649.GA14087@nevyn.them.org> Mail-Followup-To: gdb-patches@sourceware.org References: <20060927161501.GA23340@host0.dyn.jankratochvil.net> <20060927161501.GA23340@host0.dyn.jankratochvil.net> <200609271901.k8RJ1BD1030473@elgar.sibelius.xs4all.nl> <20060928172725.GA18498@host0.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060928172725.GA18498@host0.dyn.jankratochvil.net> User-Agent: Mutt/1.5.13 (2006-08-11) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-10/txt/msg00038.txt.bz2 On Thu, Sep 28, 2006 at 07:27:25PM +0200, Jan Kratochvil wrote: > Hi, > > On Wed, 27 Sep 2006 21:01:11 +0200, Mark Kettenis wrote: > ... > > This should almost certainly be handled in value.c:value_as_address(). > > You could add an i386-specific integer_to_address(), that would > > truncate the address to 32 bits. But in fact, I can't think of a > > reason why truncating to the size of a pointer shouldn't be the > > default behaviour. > > Made the default way, I also do not see the reason to keep larger addresses. > There is some note about `ADDR_BITS_REMOVE' but I believe it is only about the > lowest (0-2 or so) bits and the high bits should not hurt anyone. Please see the other message in this thread where I explained about MIPS; there, all 0x80000000 - 0xFFFFFFFF addresses will be sign extended. Suddenly printing out the extra eight F's would be really ugly IMHO. I tried to come up with a good solution to this today, but I couldn't find one; the flag we need is associated with the BFD and not easily accessible here. Maybe there should be a gdbarch flag for the property; only MIPS and sh64 set it, so duplicating the knowledge here isn't a big deal. As for the other half of the bug, Mark was talking about integer_to_address, which is separate from value_to_address where your patch tried to fix this. I think that either inside the implementations of that function, or at the one call site, is where we should fix it. That will avoid creating such addresses in the first place. There are two options: ignore high bits, or complain if the high bits would affect the address (e.g. if the integer was not properly sign or value extended). Mark liked truncate, I don't really care which. Oh, and please don't #if 0 things. Either they're right, or they're wrong. If we need them again, there's CVS history. Thanks in advance. -- Daniel Jacobowitz CodeSourcery