[PATCH] D92013: [DebugInfo] Don't use DW_OP_implicit_value for fragments

Tue Jan 5 16:59:08 PST 2021

aprantl added a comment.

> the fragmenting code would need to take the pointer size into account (one of the bugs I want to solve is that we're always assuming a 64-bit stack, whereas dwarf says it's address-sized). Knowing the address size at some point is unavoidable, so this might not be a big issue.

If we have a way to read the pointer size out of MC, for example, I don't see a problem with that. Perhaps not even if we have to encode it in the compile unit.

> Given that, it seems to me that it would be better (in line what @jmorse mentioned) to give the fragment information more prominence in the DIExpression, and enable emission code to better reason about it.

One thing to keep in mind is that DwarfExpression already may create additional fragments in order to piece together super registers for which no DWARF encoding exists from multiple subregisters. I think whatever design we choose it should be able to cope with DwarfExpression's lowering creating more fragments.

> Since DW_OP_LLVM_fragment only makes sense at the end of an expression (does it?), it's not clear to me if it's really useful to have it be a part of that expression in the first place, but it does not really matter, I think -- we could either keep them there, and create an abstraction that would let skip/ignore them, or try move them out completely.

Yes, the fact that the fragment info is stored in the expression is orthogonal to how we interpret it. Currently it is stored as operators and also accessible through the `DIExpression::getFragmentInfo()` interface (https://llvm.org/doxygen/classllvm_1_1DIExpression.html#a8bab2e1fa7810adfd2c2f687838cec5d). We could store it separately, if that is more space-efficient, or simplifies the code, but how we store it shouldn't limit how we use that information.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92013