On Thu, Jul 30, 2020 at 12:00 PM Greg Clayton via Dwarf-Discuss
<dwarf-discuss@lists.dwarfstd.org> wrote:
>
> The LTO in clang creates some really interesting DWARF... One of the latest
> things I discovered is DW_TAG_inlined_subroutine tags that are not contained
> within a DW_TAG_subprogram. I am guessing the compiler/linker wanted to
> outline an inlined function and tried its best to move the DWARF and didn't
> end up changing the tag from DW_TAG_inlined_subroutine to DW_TAG_subprogram.
(you've mentioned a couple of quirky LTO situations that I don't think
I've seen with LLVM's LTO - do you have examples of these (this one
and the other one decl file/line one discussed on llvm-commits)?
> I was thinking of adding code to "llvm-dwarfdump --verify" to detect this
> issue, but wanted to check with the DWARF list first to make sure this would
> be considered an error. So I am looking for an answer to:
>
> Is it ok for DW_TAG_inlined_subroutine with high and low PC values to appear
> on their own, not enclosed in a DW_TAG_subprogram?
The only wording I can find is:
"Each inline expansion of a subroutine is represented by a debugging
information entry with the tag DW_TAG_inlined_subroutine. Each such
entry is a direct child of the entry that represents the scope within
which the inlining occurs."
I guess this could still technically allow inlining into some place
that isn't described as a subprogram or child of a subprogram in the
DWARF (eg: inlining into a global initializer - I guess some DWARF
producer could model that as
DW_TAG_compile_unit{DW_TAG_inlined_subroutine}) - so I'd err on the
side of saying DWARF doesn't categorically disallow this.
But as an LLVM maintainer, I'd be totally fine adding that as a
verifier check to llvm-dwarfdump.
_______________________________________________
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
