- User Since
- Mar 2 2013, 8:12 AM (341 w, 5 d)
How do Fortran compilers represent regular versus inout arguments in DWARF?
Swift's let is indeed closer to C's const than to a named constant in Pascal (https://wiki.freepascal.org/Constants). The Swift language spec call them constants, and they are effectively SSA variables (with storage). But (and this is where it differs from Pascal constants) let bindings can also appear inside of composite types (there are let struct and class members) and as function arguments (unless a parameter is explicitly marked as inout, similar to Fortran). I have found that DW_TAG_const is the only mechanism that works for all of these use-cases.
Wed, Sep 18
After some consideration I concluded that this isn't the best approach either. [There's no plan to do that, but] If we ever want to serialize Swift types into DWARF then an attribute on (local) variables isn't enough to describe let-members of structs. So instead I'm currently preparing a patch (no LLVM involved) that will wrap let-bound types in DW_TAG_const_type (like the const qualifier in C).
Please be sure the watch the lldb (and other debugger) bots after committing this..
Tue, Sep 17
I'm afraid I'm going to give up on fixing the AST and return to my debuginfo-only patch.
Mon, Sep 16
Fri, Sep 13
Okay. Here is an alternative patch that implements a flag DW_AT_LLVM_constant. "The Swift Programming Language" calls let-bindings "constants" and constant seems to be a generic enough term to be generally useful.
Before creating this patch I had considered 4 options:
Thu, Sep 12
Normally I would insist on a bitcode upgrade, but since this feature is so new I think we can skip that. However, because of bitcode compatability, we might want to get the semantics right from the start. Otherwise we might have to allocate a new opcode and implement an upgrade when we need to change it in the future.
minor nits inline
Looks mostly good.
just don't record transfers until the in-locations are all known to be correct
Having suggested this, I think this is a good idea ;-)
Wed, Sep 11
Found one more stale decl.
My plan is to reuse the bit for an attribute that does not appear inside of DICompositeType, so we could leave the Verifier check in indefinitely. I should have said so though.
Thanks, that's exactly what I was looking for!
Otherwise this LGTM now.
I'm very curious what the effect of this patch on our green dragon statistics bot will be (http://green.lab.llvm.org/green/view/LLDB/job/clang-3.4-debuginfo-statistics/).
Looking great! I have one more question inline, but that is mostly about documenting the algorithm.
Okay, we should make sure that we do get the design right. I don't quite get the argument made in SourceLevelDebugInfo.rst for why the semantics are different:
Tue, Sep 10
As stated in the docs here , the meaning of a DBG_VALUE instruction changes after LiveDebugValues runs
Mon, Sep 9
This is very exciting!
This is a strict improvement and as such is fine, but there's some general cleanups that are uncovered by this that we should also be doing.
Fri, Sep 6
Thu, Sep 5
Nice! Are you planning to address the FIXME's in a later update of this patch?
Wed, Sep 4
I see we would have to do an abstract interpretation of a DIExpression together with the implicit register operand bound by the DBG_VALUE to computes all stack slots that my be touched by the expression, assuming we even know where non-frame-pointer registers point. Could you add an explanation to the comment that lays out why this isn't feasible?
Tue, Sep 3
This looks like a very good idea!
lgtm with oustanding comments addressed!
Thanks for implementing the error handling! There is one more comment inline.
Thu, Aug 29
Here is a work-in-progress alternative patch that attacks the problem by changing the AST generation to have an ObjCMethodDecl for the property accessors inside the implementation as suggested by @rjmccall.
If it helps...
Is there anything else we can print for a crashed dotest?
This makes sense, I'm kind of shocked that me missed something that obvious. Is there a big drop in variable locations with this (i.e., an improvement in accuracy)?
Currently, if a stack spill location is overwritten to by another spill instruction, nothing notices and any variables located in that slot are not terminated.