llvm dev - May 2016 - [LLVMdev] Improving the quality of debug locations / DbgValueHistoryCalculator

On Wed, May 11, 2016 at 5:14 PM, Adrian Prantl <aprantl at apple.com>
wrote:
> I hold the (perhaps somewhat extreme) position that having debug info the
> *may* be correct is worse than having no debug info at all, because it
> means that — in the end — you then cannot trust *anything* reported by the
> debugger. (There are some debatable corner cases, for example, in contrast
> to the debugger, the user may know over which path the control flow arrived
> at the current break point, but these are far in between.)
>
I don't find that extreme at all.  When I was involved with adding Location
Lists to
the Open64 backend that we were using with HP NonStop, that was the rule.  The
debugger should never lie.  We received reports from people who were surprised
when the debugger told them the "old" value of their variable when in
fact the
compiler optimized away a dead store but didn't adjust anything with the
location
list.  The dead store removal essentially invalidates the debug info.  We forgot
to adjust for that.  After it was fixed, people were happier.

We also didn't allow optimizations to reorder across statement boundaries at
-O1.
We said that -O1 was "the best optimizations we could do without making the
debug experience confusing".

While we don't have any extra resources now, debugging optimized code is
something
we took extra care with on OpenVMS Alpha with our GEM backend.  We kept some of
that in place for Itanium and would like to see our x86 port have good support
as well.  So I encourage any work that can be done now and we'll try to
offer
some cycles when we get a chance.