[binutils-gdb] DWARF: cannot break on out-of-line function nested inside inlined function.

[sergiodj+buildbot at redhat dot com]

*** TEST RESULTS FOR COMMIT 3ea89b92fb0765075a27a3a0239552ae880722ff ***

Author: Pierre-Marie de Rodat <derodat@adacore.com>
Branch: master
Commit: 3ea89b92fb0765075a27a3a0239552ae880722ff

DWARF: cannot break on out-of-line function nested inside inlined function.
Consider the following code, which defines a function, Child2,
which is itself nested inside Child1:

    procedure Foo_O224_021 is
        O1 : constant Object_Type := Get_Str ("Foo");
        procedure Child1 is
            O2 : constant Object_Type := Get_Str ("Foo");
            function Child2 (S : String) return Boolean is -- STOP
            begin
                for C of S loop
                    Do_Nothing (C);
                    if C = 'o' then
                        return True;
                    end if;
                end loop;
                return False;
            end Child2;
            R : Boolean;
        begin
            R := Child2 ("Foo");
            R := Child2 ("Bar");
            R := Child2 ("Foobar");
        end Child1;
    begin
        Child1;
    end Foo_O224_021;

On x86_64-linux, when compiled at -O2, GDB is unable to insert
a breakpoint on Child2:

    % gnatmake -g -O2 foo_o224_021
    % gdb foo_o224_021
    (gdb) b child2
    Function "child2" not defined.
    (gdb) b foo_o224_021.child1.child2
    Function "foo_o224_021.child1.child2" not defined.

The problem is caused by the fact that GDB did not create a symbol
for Child2, and this, in turn, is caused by the fact that the compiler
decided to inline Child1, but not Child2. The DWARF debugging info
first provides an abstract instance tree for Child1...

 <3><1b7b>: Abbrev Number: 29 (DW_TAG_subprogram)
    <1b7c>   DW_AT_name        : (indirect string, offset: 0x23f8): foo_o224_021__child1
    <1b82>   DW_AT_inline      : 1      (inlined)
    <1b83>   DW_AT_sibling     : <0x1c01>

... where that subprogram is given the DW_AT_inline attribute.
Inside that function there is a lexical block which has no PC
range (corresponding to the fact that this is the abstract tree):

 <4><1b87>: Abbrev Number: 30 (DW_TAG_lexical_block)

... inside which our subprogram Child2 is described:

 <5><1b92>: Abbrev Number: 32 (DW_TAG_subprogram)
    <1b93>   DW_AT_name        : (indirect string, offset: 0x2452): foo_o224_021__child1__child2
    <1b99>   DW_AT_type        : <0x1ab1>
    <1b9d>   DW_AT_low_pc      : 0x402300
    <1ba5>   DW_AT_high_pc     : 0x57
    [...]

Then, later on, we get the concrete instance tree, starting at:

 <3><1c5e>: Abbrev Number: 41 (DW_TAG_inlined_subroutine)
    <1c5f>   DW_AT_abstract_origin: <0x1b7b>
    <1c63>   DW_AT_entry_pc    : 0x4025fd
    <1c6b>   DW_AT_ranges      : 0x150

... which refers to Child1. One of that inlined subroutine children
is the concrete instance of the empty lexical block we saw above
(in the abstract instance tree), which gives the actual address
range for this inlined instance:

 <5><1c7a>: Abbrev Number: 43 (DW_TAG_lexical_block)
    <1c7b>   DW_AT_abstract_origin: <0x1b87>
    <1c7f>   DW_AT_ranges      : 0x180

This is the DIE which provides the context inside which we can
record Child2. But unfortunately, GDB does not take the abstract
origin into account when handling lexical blocks, causing it
to miss the fact that this block contains some symbols described
in the abstract instance tree. This is the first half of this patch:
modifying GDB to follow DW_AT_abstract_origin attributes for
lexical blocks.

But this not enough to fix the issue, as we're still unable to
break on Child2 with just that change. The second issue can be
traced to the way inherit_abstract_dies determines the list of
DIEs to inherit from. For that, it iterates over all the DIEs in
the concrete instance tree, and finds the list of DIEs from the
abstract instance tree that are not referenced from the concrete
instance tree. As it happens, there is one type of DIE in the
concrete instance tree which does reference Child2's DIE, but
in fact does otherwise define a concrete instance of the reference
DIE; that's (where <0x1b92> is Child2's DIE):

 <6><1d3c>: Abbrev Number: 35 (DW_TAG_GNU_call_site)
    <1d3d>   DW_AT_low_pc      : 0x4026a4
    <1d45>   DW_AT_abstract_origin: <0x1b92>

So, the second part of the patch is to modify inherit_abstract_dies
to ignore DW_TAG_GNU_call_site DIEs when iterating over the concrete
instance tree.

This patch also includes a testcase which can be used to reproduce
the issue. Unfortunately, for it to actually pass, a smal patch in
GCC is also necessary to make sure that GCC provides lexical blocks'
DW_AT_abstract_origin attributes from the concrete tree back to
the abstract tree. We hope to be able to submit and integrate that
patch in the GCC tree soon. Meanwhile, a setup_xfail has been added.

gdb/ChangeLog:

	2014-05-05  Pierre-Marie de Rodat  <derodat@adacore.com>
	* dwarf2read.c (inherit_abstract_dies): Skip
	DW_TAG_GNU_call_site dies while inheriting children of an
	abstract DIE into a scope.
	(read_lexical_block_scope): Inherit abstract DIE's for
	lexical scopes.

gdb/testsuite/ChangeLog:

        * gdb.ada/out_of_line_in_inlined: New testcase.