This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Add proper handling for non-local references in nested functions
- From: Doug Evans <xdje42 at gmail dot com>
- To: Pierre-Marie de Rodat <derodat at adacore dot com>
- Cc: Kevin Buettner <kevinb at redhat dot com>, gdb-patches at sourceware dot org
- Date: Sun, 26 Jul 2015 10:38:50 -0700
- Subject: Re: [PATCH] Add proper handling for non-local references in nested functions
- Authentication-results: sourceware.org; auth=none
- References: <54F47563 dot 4050103 at adacore dot com> <54FF0D05 dot 70907 at redhat dot com> <550C1170 dot 9070208 at adacore dot com> <55685B60 dot 3000004 at redhat dot com> <55775EB0 dot 4080701 at adacore dot com> <55AF5F7E dot 5000600 at adacore dot com> <20150722173957 dot 7ed51f18 at pinnacle dot lan> <55B0C583 dot 6050601 at adacore dot com> <20150723064408 dot 4dd8a9b2 at pinnacle dot lan> <55B112D4 dot 5010304 at adacore dot com> <20150723110653 dot 3f4e2f11 at pinnacle dot lan> <20150723112255 dot 1b14a40a at pinnacle dot lan> <55B215A8 dot 1000609 at adacore dot com>
Pierre-Marie de Rodat <derodat@adacore.com> 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.