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

[Pierre-Marie de Rodat <derodat@adacore.com>]

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. ;-)

> 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.

> I want to be perfectly clear that I do NOT want this issue to hold up
> your patch.  I'm just throwing it out there in case you want to look
> at it.

Sure. It was interesting to look at this, anyway.

-- 
Pierre-Marie de Rodat