From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 113486 invoked by alias); 26 Jul 2015 17:39:45 -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 113434 invoked by uid 89); 26 Jul 2015 17:39:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pd0-f174.google.com Received: from mail-pd0-f174.google.com (HELO mail-pd0-f174.google.com) (209.85.192.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Sun, 26 Jul 2015 17:39:43 +0000 Received: by pdrg1 with SMTP id g1so38844487pdr.2 for ; Sun, 26 Jul 2015 10:39:41 -0700 (PDT) X-Received: by 10.70.65.99 with SMTP id w3mr58300888pds.132.1437932381360; Sun, 26 Jul 2015 10:39:41 -0700 (PDT) Received: from seba.sebabeach.org.gmail.com (173-13-178-53-sfba.hfc.comcastbusiness.net. [173.13.178.53]) by smtp.gmail.com with ESMTPSA id j3sm25120605pdf.76.2015.07.26.10.39.40 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Jul 2015 10:39:40 -0700 (PDT) From: Doug Evans To: Pierre-Marie de Rodat Cc: Kevin Buettner , gdb-patches@sourceware.org Subject: Re: [PATCH] Add proper handling for non-local references in nested functions References: <54F47563.4050103@adacore.com> <54FF0D05.70907@redhat.com> <550C1170.9070208@adacore.com> <55685B60.3000004@redhat.com> <55775EB0.4080701@adacore.com> <55AF5F7E.5000600@adacore.com> <20150722173957.7ed51f18@pinnacle.lan> <55B0C583.6050601@adacore.com> <20150723064408.4dd8a9b2@pinnacle.lan> <55B112D4.5010304@adacore.com> <20150723110653.3f4e2f11@pinnacle.lan> <20150723112255.1b14a40a@pinnacle.lan> <55B215A8.1000609@adacore.com> Date: Sun, 26 Jul 2015 17:39:00 -0000 In-Reply-To: <55B215A8.1000609@adacore.com> (Pierre-Marie de Rodat's message of "Fri, 24 Jul 2015 12:38:32 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2015-07/txt/msg00777.txt.bz2 Pierre-Marie de Rodat writes: > On 07/23/2015 08:22 PM, Kevin Buettner wrote: >> I came across something else (for someone) to ponder while playing with >> the above code. I don't necessarily expect your current patch to handle >> this case, but since you've been looking at nested subprograms, you may >> have some insight into what's happening. >> >> The situation is that I want to place a breakpoint on the function p(). >> How do I do this? > >> 1) Placing a breakpoint on p without qualification does not work: >> >> (gdb) b p >> Function "p" not defined. >> Make breakpoint pending on future shared library load? (y or [n]) n > > For the record, this works in Ada: > > -- foo.adb > procedure Foo is > procedure Nested is > begin > null; > end Nested; > begin > Nested; > end Foo; > > # Program isn't even started. > (gdb) b nested > Breakpoint 1 at 0x401cca: file foo.adb, line 4. > > Bottom line is: the difference between the C and the Ada examples > resides in the partial symbols lookup: in the C example, only the > outer function has a partial symbol while in the Ada example, Nested > has one too. Why? Well, in dwarf2read.c:add_partial_subprogram there's > a special case for Ada that recurses over the child DIE. Stopping > investigation here. ;-) Yeah, I can imagine that this is at least part of the reason. We need to be as lazy as possible when reading partial syms as it's a serious perf issue. OTOH sometimes we're too lazy and then some things don't work. Requiring hyperfast reading of partial syms is becoming less important now that we have .gdb_index and soon something in the DWARF standard. So I'm working on being more complete in the partial sym reader. >> 4) Perhaps p will be visible if we run to a breakpoint in main? (Nope.) >> >> (gdb) b main >> Breakpoint 1 at 0x400525: file nested.c, line 5. >> (gdb) run >> Starting program: /mesquite2/.ironwood2/1158876/nested > > I had a quick look at how breakpoints resolution works: it sems that > lookups don't take into account the block corresponding to the > selected frame. So trying to put the breakpoint during execution looks > pointless. Yeah. We could probably do better here.