[Lldb-commits] [Review request] Materialize constant scalar value variable

[Malea, Daniel]

BTW, the test case that Andy fixes with this patch is the last one that's failing on the two Linux buildbots:

http://lab.llvm.org:8011/builders/lldb-x86_64-linux

and

http://lab.llvm.org:8011/builders/lldb-x86_64-debian-clang/



On 2013-02-21, at 7:10 PM, "Kaylor, Andrew" <andrew.kaylor at intel.com<mailto:andrew.kaylor at intel.com>> wrote:

There was a failure in the TestConstVariables.py test case where LLDB was failing to materialize the ‘index’ variable when the process being debugged had been compiled with GCC 4.6 or 4.7 (possibly others).

In this case, the ‘index’ variable location was represented as a location list and at the PC address in question its representation looked like this:

DW_OP_const2u 512 DW_OP_stack_value

It turns out that DW_OP_stack_value isn’t explicitly handled by LLDB’s DWARF expression parser, but the call to evaluate the location expression comes out with the right value anyway, having been fixed up by the calling code.

However, when the ‘location_value’ percolated back up to the ClangUserDeclMap::DoMaterializeOneVariable() method that method didn’t handle the case where location_value’s value type was ‘eValueTypeScalar’ and its context type was ‘eContextTypeClangType’.  It was assuming that the context type would always be ‘eContextTypeRegisterInfo’.

The attached patch addresses this latter problem.

It seems to me that the DWARFExpression::Evaluate() method should be explicitly handling the DW_OP_stack_value operation (it also ignores DW_OP_implicit_value), but that doesn’t seem to be required to fix the test failure in question.

Can someone review my patch and comment on whether or not this is the correct approach?

Thanks,
Andy
<const-variable.patch>_______________________________________________
lldb-commits mailing list
lldb-commits at cs.uiuc.edu<mailto:lldb-commits at cs.uiuc.edu>
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits