https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87362
--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
<2><25ce>: Abbrev Number: 7 (DW_TAG_lexical_block)
<25cf> DW_AT_abstract_origin: <0x2434>
<25d3> DW_AT_low_pc : 0x401310
<25db> DW_AT_high_pc : 0x16
<25e3> DW_AT_sibling : <0x2642>
<3><25e7>: Abbrev Number: 4 (DW_TAG_formal_parameter)
<25e8> DW_AT_abstract_origin: <0x2440>
<25ec> DW_AT_location : 0xfef (location list)
<25f0> DW_AT_GNU_locviews: 0xfed
the issue is probably the DW_TAG_formal_parameter DIE here which gdb likely
doesn't expect as child of a DW_TAG_lexical_block. Nope, forcing it to
be a DW_TAG_variable doesn't help.
So we fail to output this as inlined function body because the location
of the call of the split part is UNKNOWN_LOCATION and we have
static inline bool
inlined_function_outer_scope_p (const_tree block)
{
return LOCATION_LOCUS (BLOCK_SOURCE_LOCATION (block)) != UNKNOWN_LOCATION;
}
so inlined split parts are _not_ inlined_function_outer_scope_p. But then
this should reproduce w/o LTO (debug) as well. The inlining happens at IPA
time btw. Maybe this was desired somehow (the ipa-split.c code doesn't have
a comment reflecting that though).
As said, both issues should be latent ... indeed the issue happens
in genchecksum unpatched as well.
OK, so I think this is a gdb issue in that read_func_scope doesn't seem to
be prepared to handle the case that this concrete instance is from a CU
with a different language and parameter DIEs are processed not the same
as variables in contained scopes with respect to setting the language.
Not sure why exactly this doesn't show more often (or w/o the patch) is
a mystery to me... (recursive inlining might show a similar "pattern",
but eventually the inlined-subroutine path has a similar behavior for
those dups).
So we might be able to fix that by using DW_TAG_inlined_subroutine (will
check that). That seems to help.
Index: gcc/tree-inline.c
===================================================================
--- gcc/tree-inline.c (revision 264418)
+++ gcc/tree-inline.c (working copy)
@@ -4531,6 +4531,8 @@ expand_call_inline (basic_block bb, gimp
BLOCK_ABSTRACT_ORIGIN (id->block) = fn;
BLOCK_SOURCE_LOCATION (id->block)
= LOCATION_LOCUS (gimple_location (stmt));
+ if (LOCATION_LOCUS (gimple_location (stmt)) == UNKNOWN_LOCATION)
+ BLOCK_SOURCE_LOCATION (id->block) = BUILTINS_LOCATION;
prepend_lexical_block (gimple_block (stmt), id->block);
}
That will of course cause gdb to step into foo itself if foo was split
and later re-merged by inlining.
Of course it's still a gdb bug and the above is only a workaround (well,
IMNSHO).
Tom - maybe you can have a look what it would take to make gdb handle
symbol language "correctly" here (it all seems to be messed up a bit).
For example if I have an DW_TAG_inlined_subroutine gdb doesn't switch
to the callees language when that differs from the caller.
