<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">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).<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Courier New"">DW_OP_const2u 512 DW_OP_stack_value<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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’.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The attached patch addresses this latter problem.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Can someone review my patch and comment on whether or not this is the correct approach?<o:p></o:p></p>
<p class="MsoNormal"><br>
Thanks,<o:p></o:p></p>
<p class="MsoNormal">Andy<o:p></o:p></p>
</div>
</body>
</html>