On Tue, Sep 25, 2018 at 6:34 AM, Richard Biener <rguent...@suse.de> wrote: > > Hi, > > the following two patches both "fix" the immediate issue of gdb > asserting with > > ../../gdb/dwarf2read.c:9730: internal-error: void > dw2_add_symbol_to_list(symbol*, pending**): Assertion `(*listhead) == NULL > || (SYMBOL_LANGUAGE ((*listhead)->symbol[0]) == SYMBOL_LANGUAGE (symbol))' > failed. > > on most LTO compiled objects now. I tracked this down to us generating > bogus DWARF (as I read it), specifically an inline instance that is > output not as DW_TAG_inlined_subroutine but represented as > DW_TAG_lexical_block (but otherwise with same children and abstract > origin). This is because we do have (quite a lot :/) inlined calls > with LOCATION_LOCUS (gimple_location (stmt)) == UNKNOWN_LOCATION > and thus inlined_function_outer_scope_p returning false on the > BLOCK the inliner generates. > > A third yet untested alternative would be to store the combined > locus|BLOCK location in BLOCK_SOURCE_LOCATION and in > inlined_function_outer_scope_p check for literal UNKNOWN_LOCATION > instead of looking at LOCATION_LOCUS. We'd have to properly > remap the locus in remap_block (which may be a chicken-and-egg issue) > to not run foul of what I fixed with r196542. But somehow that > runs into issues with the new debug notes Alex added last year. > Similarly keying on BLOCK_ABSTRACT_ORIGIN rather than > BLOCK_SOURCE_LOCATION in inlined_function_outer_scope_p. > > Any ideas? The least fallout is probably produced by the > BUILTINS_LOCATION "hack" (but dwarf2out.c assumes that the > locations are sensible and thus will output some "interesting" > src-coords for the lexical block, <built-in>:0 respectively).
Is there a reason not to use DECL_SOURCE_LOCATION (fn)? Jason
