[llvm-dev] Propagation of debug information for variable into basic blocks.

Keith Walker via llvm-dev llvm-dev at lists.llvm.org
Wed Sep 21 10:29:14 PDT 2016


Adrian,

I am currently investigating issues where variables that one would expect to be available in a debugger are not in code that is compiled at optimisations other than -O0

The main problem appears to be with the LiveDebugValues::join() method because it does not allow variables to be propagated into blocks unless all predecessor blocks have an Outgoing Location for that variable.

As a simple example in the C code:

int func2( int);
void func(int a) {
        int b = func2(10);
        for(int i = 1; i < a; i++) {
                func2(i+b);
        }
}

One would reasonable expect when stopped within the body of the for loop that you could access the variable b in a debugger (especially as it is actually referenced in the loop).

Unfortunately this is often not the case.   I believe that this is due to the requirement stated in the descriptive comment of LiveDebugValues::join() which states:
  "if the same source variable in all the predecessors of @MBB reside in the same location."

In our simple example we end up with a series of blocks like

  BB#0   Initial-block         Predecessor:                                     Successor: BB#2

  BB#1  for-body                Predecessor: BB#2                          Successor: BB#2

  BB#2  for-condition       Predecessor: BB#0 BB#1               Successor: BB#1 BB#3

  BB#3  after-for                Predecessor: BB#2                          Successor :

Now b is initially defined to be an "Outgoing Location" to BB#0,  but it isn't imported into BB#2 because it is not defined as an "Outgoing Location" for both predecessor blocks BB#0 and BB#1.

So the outcome is that the variable b is not available in the debugging information while in BB#2 (or BB#1).

Now changing the algorithm in LiveDebugValues::join() to include all Outgoing Locations from predecessor blocks appears to significantly improve the visibility of variables in such cases.    However I am worried that doing this possibly propagates the variables more than intended ... or maybe it is the right thing to do.

So if you have any suggestions or alternative approaches to consider then please let me know.

Keith



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160921/cae5b4ea/attachment.html>


More information about the llvm-dev mailing list