From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6961 invoked by alias); 14 Feb 2011 11:59:58 -0000 Received: (qmail 6953 invoked by uid 22791); 14 Feb 2011 11:59:57 -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 11:59:52 +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 p1EBxgZF021812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 Feb 2011 06:59:42 -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 p1EBxeKi022691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Feb 2011 06:59:42 -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 p1EBxehL017567; Mon, 14 Feb 2011 12:59:40 +0100 Received: (from jkratoch@localhost) by host1.dyn.jankratochvil.net (8.14.4/8.14.4/Submit) id p1EBxd9I017490; Mon, 14 Feb 2011 12:59:39 +0100 Date: Mon, 14 Feb 2011 11:59:00 -0000 From: Jan Kratochvil To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [unavailable values part 1, 03/17] expose list of available ranges to common code Message-ID: <20110214115939.GC2454@host1.dyn.jankratochvil.net> References: <201102071429.19096.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201102071429.19096.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/msg00264.txt.bz2 On Mon, 07 Feb 2011 15:29:18 +0100, Pedro Alves wrote: > For the record, I tried making all this range handling be > done with addrmaps, but, I found out it was much more > trouble than it's worth. I wanted to suggest it first, even if the code may be larger those are just stubs while the expensive bug-prone core could exist in a single instance. Moreover coreaddr is still more effective, at least algorithmically. (not a concern here as you state.) > +/* qsort comparison function, that compares mem_ranges. */ "and sorts them in ascending order according to their START." > +void > +normalize_mem_ranges (VEC(mem_range_s) *ranges) /* This function must not use any VEC operation on RANGES which may reallocate the memory block as the callers keep the original memory location. */ > +{ > + if (!VEC_empty (mem_range_s, ranges)) > + { > + struct mem_range *ra, *rb; > + int a, b; > + > + qsort (VEC_address (mem_range_s, ranges), > + VEC_length (mem_range_s, ranges), > + sizeof (mem_range_s), > + compare_mem_ranges); > + > + a = 0; > + ra = VEC_index (mem_range_s, ranges, a); > + for (b = 1; VEC_iterate (mem_range_s, ranges, b, rb); b++) > + { > + /* If mem_range B overlaps or is adjacent to mem_range A, > + merge them. */ > + if (rb->start <= ra->start + ra->length) > + { > + ra->length = (rb->start + rb->length) - ra->start; > + continue; /* next b, same a */ > + } Here if `ra->start == rb->start && ra->length > rb->length' this normalization will lose the `ra->length - rb->length' part. Not sure if gdbserver can generate such data but at least this function looks general enough so it should behave general enough. > +struct mem_range > +{ > + /* Lowest address in the range. */ > + CORE_ADDR start; > + > + /* Length of the range. */ > + int length; > +}; Why couldn't GDB become 64bit clean - that is CORE_ADDR length. It is not supported by the internal gdbserver representation but this structure tries to be more general. > +/* Return in RESULT, the set of collected memory in the current > + traceframe, found within the LEN bytes range starting at MEMADDR. > + Returns true if the target supports the query, otherwise returns > + false. */ (and RESULTS remains always NULL). > + > +int > +traceframe_available_memory (VEC(mem_range_s) **result, > + CORE_ADDR memaddr, ULONGEST len) ULONGEST? It is `int' in `struct mem_range', it should just match the type of `memaddr'. > +{ > + struct traceframe_info *info = get_traceframe_info (); > + > + if (info != NULL) > + { > + struct mem_range *r; > + int i; > + > + *result = NULL; I would make this line unconditional. Or the function comment should be different. > + for (i = 0; VEC_iterate (mem_range_s, info->memory, i, r); i++) > + if (mem_ranges_overlap (r->start, r->length, memaddr, len)) > + { > + ULONGEST lo1, hi1, lo2, hi2; > + struct mem_range *nr; > + > + lo1 = memaddr; > + hi1 = memaddr + len; > + > + lo2 = r->start; > + hi2 = r->start + r->length; > + > + nr = VEC_safe_push (mem_range_s, *result, NULL); > + > + nr->start = max (lo1, lo2); > + nr->length = min (hi1, hi2) - nr->start; > + } > + > + normalize_mem_ranges (*result); > + return 1; > + } > + > + return 0; > +} > + Thanks, Jan