[PATCH] D67563: Debug Info: Add support for named constants

David Blaikie via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Sep 13 11:35:56 PDT 2019


dblaikie added a comment.

In D67563#1669828 <https://reviews.llvm.org/D67563#1669828>, @vsk wrote:

> IIUC @jingham makes the argument here <https://bugs.swift.org/browse/SR-10544> that DW_TAG_constant isn't appropriate for swift's 'let', and instead suggests attaching DW_AT_const_value to the DW_TAG_variable (which lldb seems to already understand). Wdyt of that as an alternative?


Yeah, sounds like "let" variables can be runtime values like const int in C (eg: "void f(int g) { const int h = g; ... }") - which, like Jim said, I don't think is what's meant by DWARF's "true constants" (though it'd be nice if DWARF were a bit more descriptive there).

That said, inversely - since Swift doesn't use DWARF tags to describe types, you don't have the option of describing these in the same way as "const" variables in C - because you can't put a DW_TAG_const_type around the type (yeah, that wouldn't quite match the source even if you could do it - but I think it'd be a pretty good analogy, really). So in that sense, I could see how using "DW_TAG_constant" might be a reasonable workaround - if not for the parameter issue. If you can have a "let" be a parameter, then that needs to be a DW_TAG_formal_parameter and can't be DW_TAG_constant (as Jim says) - so you'll need some other representation to cope with this anyway.

DW_AT_const_value probably isn't that representation, though - because that's for, even moreso (perhaps, only due to the ambiguity of DW_TAG_constant's specification) than DW_TAG_constant - DW_AT_const_value stores a compile-time, storage-less things which not all "let" values seem to be.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67563





More information about the llvm-commits mailing list