From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14710 invoked by alias); 14 Feb 2011 16:00:22 -0000 Received: (qmail 14697 invoked by uid 22791); 14 Feb 2011 16:00:20 -0000 X-SWARE-Spam-Status: No, hits=-6.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 14 Feb 2011 16:00:15 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p1EG06u3005677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 Feb 2011 11:00:06 -0500 Received: from host1.dyn.jankratochvil.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p1EG04BP007664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Feb 2011 11:00:06 -0500 Received: from host1.dyn.jankratochvil.net (localhost [127.0.0.1]) by host1.dyn.jankratochvil.net (8.14.4/8.14.4) with ESMTP id p1EG04nI024169; Mon, 14 Feb 2011 17:00:04 +0100 Received: (from jkratoch@localhost) by host1.dyn.jankratochvil.net (8.14.4/8.14.4/Submit) id p1EG03TN024166; Mon, 14 Feb 2011 17:00:03 +0100 Date: Mon, 14 Feb 2011 17:28:00 -0000 From: Jan Kratochvil To: Pedro Alves Cc: gdb-patches@sourceware.org, Tom Tromey Subject: Re: [unavailable values part 1, 01/17] base support for unavailable value contents Message-ID: <20110214160002.GA14664@host1.dyn.jankratochvil.net> References: <201102071427.55970.pedro@codesourcery.com> <201102101930.26399.pedro@codesourcery.com> <20110214115919.GA2454@host1.dyn.jankratochvil.net> <201102141259.11583.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201102141259.11583.pedro@codesourcery.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-02/txt/msg00284.txt.bz2 On Mon, 14 Feb 2011 13:59:11 +0100, Pedro Alves wrote: > On Monday 14 February 2011 11:59:19, Jan Kratochvil wrote: > > On Thu, 10 Feb 2011 20:30:26 +0100, Pedro Alves wrote: > > > +static int > > > +ranges_contain_p (VEC(range_s) *ranges, int offset, int length) > > > > Couldn't even this function stick with the `overlap' term? > > I guess it could. There's already a ranges_overlap function > though. I'm open to concrete suggestions, though IMO this > isn't worth the bother. mem_ranges_list_overlaps? Contrary to: mem_ranges_overlap (CORE_ADDR start1, int len1, CORE_ADDR start2, int len2) > If we switch the logic, we need to always allocate the VEC with a single > range covering the whole contents, and then punch holes as we > find them. As that's more wasteful in terms of memory, I opted > for the current logic. Or maybe we could special case the empty > case as meaning all-available? It might work. I agree but I do not consider this difference so important. > > it would also enable storing discontiguous memory with > > a value. > > Can't see why you can't keep the "unavailable" ranges logic > even if we store discontiguous memory in values. It is questionable if it is the same. I thought that any memory which is not stored is . Another look may be the memory is of three kinds: * stored/available * marked as * not stored, internal GDB error if an access is attempted In the three-kinds model you are right these two features are unrelated. Anyway your patchset is checked in and I do not plan to place much new features on top of archer-jankratochvil-vla before it gets merged in some form. > I haven't looked at your code yet though. archer-jankratochvil-vla currently does not contain any discontiguous memory ranges code. I mentioned it as it could benefit from such a feature. Thanks, Jan