From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24916 invoked by alias); 14 Jun 2002 21:19:12 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 24899 invoked from network); 14 Jun 2002 21:19:11 -0000 Received: from unknown (HELO cygnus.com) (205.180.83.203) by sources.redhat.com with SMTP; 14 Jun 2002 21:19:11 -0000 Received: from theotherone.redhat-remotie.org (romulus.sfbay.redhat.com [172.16.27.251]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id OAA22735; Fri, 14 Jun 2002 14:18:52 -0700 (PDT) Received: from localhost (localhost.fidalgo.net [127.0.0.1]) by theotherone.redhat-remotie.org (Postfix) with ESMTP id 24839BB410; Fri, 14 Jun 2002 14:19:04 -0700 (PDT) Date: Fri, 14 Jun 2002 14:19:00 -0000 From: Don Howard X-X-Sender: To: Andrew Cagney Cc: Kevin Buettner , Subject: Re: [Patch] Another small memattr fix. In-Reply-To: <3D0A524F.90405@cygnus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-06/txt/msg00253.txt.bz2 On Fri, 14 Jun 2002, Andrew Cagney wrote: > > On Jun 14, 12:44pm, Don Howard wrote: > > > > > >> The strings are arbitrary expressions and are converted to address via > >> parse_and_eval_address(), which does not flag overflow: > >> > >> mem_command (char *args, int from_tty) > >> { > >> CORE_ADDR lo, hi; > >> char *tok; > >> struct mem_attrib attrib; > >> > >> if (!args) > >> error_no_arg ("No mem"); > >> > >> tok = strtok (args, " \t"); > >> if (!tok) > >> error ("no lo address"); > >> lo = parse_and_eval_address (tok); > >> > >> tok = strtok (NULL, " \t"); > >> if (!tok) > >> error ("no hi address"); > >> hi = parse_and_eval_address (tok); > >> > >> mabe parse_and_eval_address could detect overflow and throw an error(). > > On real hardware, addresses overflow causes it to wrap. The problem of > signed vs unsigned addresses is also lurking in there as well. > > From memory there is a tabled proposal to add a CORE_ADDR alu object so > that CORE_ADDR arrithmetic is correct. > > > Maybe I'm missing something, but it seems to me that you're still left > > with the problem of how to represent the maximum address + 1. (Throwing > > an error doesn't really help, does it?) > > > > > >> Another possiblity is that the interface could be changed, making the > >> upper bound inclusive also. > > > > > > This sounds better. > > > > So, on a 16 bit machine, you could say > > > > mem 0xf000 0xffff ro > > > > to indicate that the top 4096 bytes are read-only. > > I can think of three alternatives: > > [base, bound) > [base, bound] > [base, base+size-1) > > The first one is what the doco says and has been there for a while so I > don't think that changing it is a good idea. > > Internally, I suspect base+size-1 is the best representation. However, > for the user interface, is there anything that really says that: > > mem 0xfffffff0 0 > > is either illegal or poorly defined? The fact that the first bound is inclusive and the second is exclusive implies that to me. Also, the current implemntation enforces it. How's this: let the parser find the size of the region for us: labs (parse_and_evaluate_long (tok1 " - " tok2)); That seems to avoid the max int problem. Then we can use base and size as the internal representation. -- dhoward@redhat.com gdb engineering