<p dir="ltr"><br>
On Aug 12, 2014 7:17 AM, "David Blaikie" <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
><br>
> >>! In D3714#11, @echristo wrote:<br>
> > The debug info side of things sounds ok for now, it might be nice to figure out some way to represent the value in the future with the type.<br>
><br>
> Yeah - I believe that's in the territory of DWARF extensions/improvements. For now, so far as I understand DWARF, you can only describe the value of the variable (a pointer in this case, and something we don't have anymore - we'd need the opposite of DW_OP_deref (DW_OP_addr_of?)). Not sure if this overlaps with the broader problem of things like Argument Promotion, but I think it does.</p>

<p dir="ltr">Correct. </p>
<p dir="ltr">><br>
> Prior to that, though, we may need a better structured representation of addresses - I know, for example, that a screwed up when fixing the pass-by-non-trivial-copy (fixing the bug where we described those parameters as references instead of values) - by tagging the DIVariable itself with the "indirect" flag. That's no good in cases like this - we'll need to be able to add/remove such description on a per-variable-instance basis, so it should go in the dbg.value/declare/whatnot in a way that things like ArgPromo can see it and remove it if they get fancy (hey, we inlined your copy ctor/dtor and found nothing interesting, so we promoted your pass-by-non-trivial-copy to a trivial copy, but we can still describe the location of that variable, etc... - we still have the issue with "how does the debugger call this function now that it doesn't match the ABI" which we've also bantered about a bit)</p>

<p dir="ltr">Yep. </p>
<p dir="ltr">-eric<br>
><br>
> <a href="http://reviews.llvm.org/D3714">http://reviews.llvm.org/D3714</a><br>
><br>
><br>
</p>