Re: [Dwarf-Discuss] modeling different address spaces
For optimized code involving multiple address spaces it is possible to run into cases where the location of a source language variable requires multiple address spaces. For example, a source variable may be optimized and different pieces may be in different places including memory of multiple address spaces, registers, etc. Describing this situation with a DW_AT_address_class on a source language variable is not possible as it provides a single address space that applies to the variable as a whole. The concept of "address space" is not available on the expression stack where a composite location description is created. Instead, making address space a property of memory location descriptions and making location descriptions a first-class concept on the expression stack solves the problem in a general way and leads to other nice properties. Thanks, -Tony ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] Question about DW_TAG_inlined_subroutine tags
> On Jul 30, 2020, at 12:21 PM, David Blaikie wrote:
>
> On Thu, Jul 30, 2020 at 12:00 PM Greg Clayton via Dwarf-Discuss
> 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
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] Question about DW_TAG_inlined_subroutine tags
On Thu, Jul 30, 2020 at 12:00 PM Greg Clayton via Dwarf-Discuss
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
