[PATCH] D56587: Fix sign/zero extension in Dwarf expressions.

Adrian Prantl via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Feb 5 09:47:23 PST 2019


aprantl added a comment.

In D56587#1385106 <https://reviews.llvm.org/D56587#1385106>, @markus wrote:

> > If you choose this path, one way to solve the issue of what to do with the dangling types that are produced by the conversion operations would be to create them in a separate DICompileUnit with a compiler-generated name and location. This way the types should get uniqued automatically during LTO, and you don't need to worry about llvm-link & friends.
>
> Not sure that I understand this comment right now. Perhaps I will run into the issue you describe later on but for now my mind is not there just yet :)


My mistake, I mistakenly thought that DIBasicTypes would be owned by a DICompileUnit, but that is not the case, they are freestanding.

> 
> 
>> What other DWARF5 operations do you have in mind that would need pointers into the debug type hierarchy?
> 
> For example I imagine that  DW_OP_regval_type, DW_OP_deref_type and DW_OP_const_type could come in handy to set the type of the expression stack. The "each element
>  of the stack is the size of an address on the target machine" of Dwarf4 is a rather annoying limitation for our target.

All three of these operations expect a DW_TAG_basic_type as argument. So we could easily introduce a DW_OP_LLVM_basic_type <signedness> <bits> operation that gets expanded in AsmPrinter into DW_TAG_basic_types like you do now and thus avoid having to deal with TrackingMDRefs. This would also reduce the memory footprint of all DIExpressions that don't need a type argument.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56587/new/

https://reviews.llvm.org/D56587





More information about the llvm-commits mailing list