Re: [PATCH v2 00/13] [gdb/symtab, cc-with-dwz] Fix gdb.cp/breakpoint-locs.exp

[Tom Tromey <tom@tromey.com>]

>>>>> "Tom" == Tom de Vries <tdevries@suse.de> writes:

>> However, in theory those should also be emitted at the top level with
>> DW_AT_inline, with a value of either DW_INL_inlined or
>> DW_INL_declared_inlined.

Tom> In the gdb.cp/breakpoint-locs.exp cc-with-dwz case we have:

Tom>     <30>   DW_AT_inline      : 3        (declared as inline and inlined)

Tom> and I think what you're describing matches most closely DIE 0x2e
Tom> (though I haven't found DW_INL_inlined or DW_INL_declared_inlined in
Tom> the dwarf produced for the test-case, also not with gcc 12 and
Tom> -gdwarf-5).

readelf / objdump don't print the symbolic name here, but that's
actually what you're seeing.  From dwarf2.h:

    /* Inline attribute.  */
    enum dwarf_inline_attribute
      {
        DW_INL_not_inlined = 0,
        DW_INL_inlined = 1,
        DW_INL_declared_not_inlined = 2,
        DW_INL_declared_inlined = 3
      };

>> Would having entries for these be enough to provoke the desired CU
>> expansion?  If so it may be just a matter of marking some more abbrevs
>> as "interesting".

Tom> The problem is that the DIE 0x2e has been moved to a PU, and as
Tom> consequence in the current implementation will cause expansion of only
Tom> a single CU.

Ok, I see.  Won't this fail with .gdb_index as well then?  Because IIRC
that attributes symbols from a PU to the canonical includer.

Anyway it seems better to me to record inclusions more precisely and
then expand more often (depending on the lookup) than to spend a lot of
time recursing into C++ subroutines.

Tom