Re: [PATCH] Add proper handling for non-local references in nested functions

[Doug Evans <xdje42@gmail.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.