From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28272 invoked by alias); 14 Jun 2002 20:30:13 -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 28236 invoked from network); 14 Jun 2002 20:30:09 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 14 Jun 2002 20:30:09 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id B96D53CCC; Fri, 14 Jun 2002 16:30:07 -0400 (EDT) Message-ID: <3D0A524F.90405@cygnus.com> Date: Fri, 14 Jun 2002 13:30:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020613 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Buettner Cc: Don Howard , gdb-patches@sources.redhat.com Subject: Re: [Patch] Another small memattr fix. References: <1020614200008.ZM24922@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-06/txt/msg00251.txt.bz2 > 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? Perhaphs allow that and not stuff like: mem 0xfffffff0 0xffffffff0 Andrew