From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 45339 invoked by alias); 26 Jun 2019 17:24:50 -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 45210 invoked by uid 89); 26 Jun 2019 17:24:50 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-9.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy= X-HELO: gateway31.websitewelcome.com Received: from gateway31.websitewelcome.com (HELO gateway31.websitewelcome.com) (192.185.144.96) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 26 Jun 2019 17:24:48 +0000 Received: from cm10.websitewelcome.com (cm10.websitewelcome.com [100.42.49.4]) by gateway31.websitewelcome.com (Postfix) with ESMTP id 62C5112FDF78 for ; Wed, 26 Jun 2019 12:24:47 -0500 (CDT) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id gBf5h1mXw2PzOgBf5hGez7; Wed, 26 Jun 2019 12:24:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=vio1DHocHGYPjDbiHvXDAF1nbvvfbyR+fAB54kkwT1I=; b=gL+Gq2VXBH5VPVriqhzb1SkQI4 XAKIDG73etFhKtHq3YvIoDdFIucfkHJYJirG+dA4Rg7a0jNCwjHEw/zJMAEGbX4/cOcOMLOVsThRv GFj6yjRcXZ14/S6htWsninOBV; Received: from 75-166-12-78.hlrn.qwest.net ([75.166.12.78]:41522 helo=murgatroyd) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hgBf5-0023wq-34; Wed, 26 Jun 2019 12:24:47 -0500 From: Tom Tromey To: Kevin Buettner Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 0/4] Non-contiguous address range bug fixes / improvements References: <20190608195434.26512-1-kevinb@redhat.com> Date: Wed, 26 Jun 2019 17:24:00 -0000 In-Reply-To: <20190608195434.26512-1-kevinb@redhat.com> (Kevin Buettner's message of "Sat, 8 Jun 2019 12:54:30 -0700") Message-ID: <87tvcc5kf5.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2019-06/txt/msg00600.txt.bz2 >>>>> "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. thanks, Tom