[llvm-dev] RFC: Introduce DW_OP_LLVM_memory to describe variables in memory with dbg.value

[Robinson, Paul via llvm-dev]

> -----Original Message-----
> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Alex
> Bradbury via llvm-dev
> Sent: Wednesday, September 06, 2017 3:25 AM
> To: Reid Kleckner
> Cc: llvm-dev
> Subject: Re: [llvm-dev] RFC: Introduce DW_OP_LLVM_memory to describe
> variables in memory with dbg.value
> 
> On 5 September 2017 at 21:00, Reid Kleckner via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > Debug info today handles two cases reasonably well:
> > 1. At -O0, dbg.declare does a good job describing variables that live at
> > some known stack offset
> > 2. With optimizations, variables promoted to SSA can be described with
> > dbg.value
> >
> > This leaves behind a large hole in our optimized debug info: variables
> that
> > cannot be promoted, typically because they are address-taken. This is
> > https://llvm.org/pr34136, and this RFC is mostly about addressing that.
> >
> > The status today is that instcombine removes all dbg.declares and
> > heuristically inserts dbg.values where it can identify the value of the
> > variable in question. This prevents us from having misleading debug
> info,
> > but it throws away information about the variable’s location in memory.
> 
> Hi Reid, thanks for writing such a clear summary of the problem that
> this RFC addresses. I was wondering if there is any sort of
> methodology for quantifying the "quality" of debug information? e.g.
> the gap between the current debug information and 'ideal' debug info?

Hi Alex,

The usual oracle for execution-related debug info is "what you get at -O0."
More abstractly, you would like to be able to stop at any source statement,
and have any in-scope variable's value available for display (and possibly
for modification).

At my previous employer we built a tool that compared the set of breakpoint 
locations at -O0 to -O1/-O2, and also compared the ranges where a variable 
had a defined location to the range of code for its lexical scope.  This 
gives you computable metrics such that you can readily tell when things have
gotten "better" or "worse" compared to some previous compiler version (or 
competitor compiler).

There's no open-source tool that does this at the moment, that I'm aware of, 
although we are working on publishing our DIVA tool (see our lightning talk
at EuroLLVM earlier this year).
--paulr