From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14037 invoked by alias); 21 Jun 2002 21:20:57 -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 14002 invoked from network); 21 Jun 2002 21:20:52 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 21 Jun 2002 21:20:52 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id A1B273D66; Fri, 21 Jun 2002 17:20:51 -0400 (EDT) Message-ID: <3D1398B3.8090003@cygnus.com> Date: Fri, 21 Jun 2002 14:20: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: Don Howard Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] memattr bounds References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-06/txt/msg00442.txt.bz2 > The following addresses edge conditions in the mem command by making a > special case for upper bound == 0. When the upper bound is zero, it is > assumed that the user wants an upper bound of max CORE_ADDR+1. Currently, > it's not possible to define a memory region with zero as it's upper bound, > so this should not conflict with any current usage. Don't forget to follow up with something for the doco. > The patch also corrects a bug that allowes the definition of overlapping > memory regions, where the new region starts below an existing region and > extends above it. (Or does someone think that is a feature?) I would treat it as a bug. Some of the simulators have a mechanism that is similar to memattr where the address map is layered and each address range is assigned to a layer. Within a layer things can't overlap but between layers they can - this making the search well defined. Adding such a mechanism to memattr would be a useful but perhaps best left to the reader :-) > 2002-06-21 Don Howard > > * memattr.c (create_mem_region): Treat hi == 0 as a special case > that means max CORE_ADDR+1. > (lookup_mem_region): Ditto. > (mem_info_command): Ditto. > > Yes, 1.5 tweaks: > - if ((lo >= n->lo && lo < n->hi) || > - (hi > n->lo && hi <= n->hi)) > + if ((lo >= n->lo && (lo < n->hi || n->hi == 0)) || > + (hi > n->lo && (hi <= n->hi || n->hi == 0)) || > + (lo <= n->lo && (hi >= n->hi || hi == 0))) The ``||'' goes at the start of the line (the old code was also wrong :-) > if (TARGET_ADDR_BIT <= 32) > - tmp = local_hex_string_custom ((unsigned long) m->hi, "08l"); > + tmp = local_hex_string_custom ((unsigned long) (m->hi ? m->hi : ~0), "08l"); > else > - tmp = local_hex_string_custom ((unsigned long) m->hi, "016l"); > + tmp = local_hex_string_custom ((unsigned long) (m->hi ? m->hi : ~0), "016l"); > Consider lifting the ``(m->hi ? m->hi : ~0)'' out to before the if(). which ever, it can then go straight in. Andrew