From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9313 invoked by alias); 3 Jul 2019 20:10:27 -0000 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 Received: (qmail 9301 invoked by uid 89); 3 Jul 2019 20:10:26 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=Kevin X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 03 Jul 2019 20:10:25 +0000 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 966F730821FF; Wed, 3 Jul 2019 20:10:16 +0000 (UTC) Received: from f29-4.lan (ovpn-117-224.phx2.redhat.com [10.3.117.224]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 697A816A26; Wed, 3 Jul 2019 20:10:14 +0000 (UTC) Date: Wed, 03 Jul 2019 20:10:00 -0000 From: Kevin Buettner To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 0/4] Non-contiguous address range bug fixes / improvements Message-ID: <20190703131013.0db569f9@f29-4.lan> In-Reply-To: <87tvcc5kf5.fsf@tromey.com> References: <20190608195434.26512-1-kevinb@redhat.com> <87tvcc5kf5.fsf@tromey.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-07/txt/msg00075.txt.bz2 On Wed, 26 Jun 2019 11:24:46 -0600 Tom Tromey wrote: > >>>>> "Kevin" == Kevin Buettner writes: > > Kevin> This four part series fixes some bugs associated with GDB's non-contiguous > Kevin> address range support. > > This is not really related to your patches, but since you have been > working in this area, I thought I'd ask. > > I ran into a case where gdb will mis-report a breakpoint location in a > certain situation (that is, "info b" will show something odd for the > source location). After debugging for a while, my theory is that the > problem occurs because the executable has non-contiguous address ranges. > > In particular, find_pc_sect_line is written to first find the symtab > with the smallest overall range that encloses the PC, and then to find a > matching symbol in the symtab. But, with non-contiguous ranges, this > can yield a sub-optimal result -- because the overall range of a symtab > not longer really says anything about whether it holds the best symbol. > > Have you seen anything like this? (I guess not since I'd imagine you'd > have written a patch ;-) > > I was thinking perhaps the best fix would be to search the blockvectors > for a definitively enclosing block. I wonder what you think. Hi Tom, I hadn't encountered this (yet), but I have no doubt that there are still some things to be fixed. I'll play around with my test case to see if I can reproduce the behavior that you've described. Kevin