[Dwarf-Discuss] Question about DW_TAG_inlined_subroutine tags

[Greg Clayton]

> On Jul 30, 2020, at 12:21 PM, David Blaikie <dblaikie at gmail.com> wrote:
> 
> On Thu, Jul 30, 2020 at 12:00 PM Greg Clayton via Dwarf-Discuss
> <dwarf-discuss at 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)?

We have this some private company code, but I will see if I can reproduce this by building some LLVM or clang tools and I will file some bugs if I can reproduce.
> 
>> 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.

Sounds good. I will submit a patch shortly.

Greg