<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1256">
<style type="text/css" id="owaParaStyle"></style>
</head>
<body fpstyle="1" ocsi="0">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">Hi,
<div><br>
</div>
<div>I have an issue with frame unwinding using .eh_frame</div>
<div><br>
</div>
<div>The PC for our architecture is a dword pointer. T<span style="font-size: 10pt;">o enable the LLDB frame unwinder to see it as a byte pointer when using CFI, I encoded the return address value in a DWARF expression.</span></div>
<div><span style="font-size: 10pt;"><br>
</span></div>
<div><span style="font-size: 10pt;">When RA (r3) is in a register the expression is:</span></div>
<div> DW_CFA_val_expression: r3 (DW_OP_reg3 (r3); DW_OP_lit2; DW_OP_shl)</div>
<div><br>
</div>
<div><span style="font-size: 10pt;">When RA has been pushed on the stack (r2), the expression is: </span></div>
<div> DW_CFA_val_expression: r3 (DW_OP_breg2 (r2): -8; DW_OP_deref; DW_OP_lit2; DW_OP_shl)</div>
<div><br>
</div>
<div>Up until r217185 the stack unwinding was working fine. But since we resynced our code with the more recent r221593, the return address is not evaluated according to the DWARF expression. The unwinder just uses R3.</div>
<div><br>
</div>
<div>
<div>(lldb) bt</div>
<div>th1/fr0 requested caller's saved PC but this UnwindPlan uses a RA reg; getting r3 (3) instead </div>
<div>th1/fr0 supplying caller's register r3 (3) from the live RegisterContext at frame 0, saved in 3 <span style="font-size: 10pt;"><<<<<<<<<<<<</span></div>
<div> th1/fr1 pc = 0x100014 </div>
<div>th1/fr0 supplying caller's saved r2 (2)'s location using eh_frame CFI UnwindPlan</div>
<div>th1/fr0 supplying caller's register r2 (2) from the stack, saved at CFA plus offset -4</div>
<div> th1/fr1 fp = 0x7fff7f8</div>
<div>th1/fr0 supplying caller's stack pointer r1 (1) value, computed from CFA</div>
<div> th1/fr1 sp = 0x7fff7d8</div>
</div>
<div><br>
</div>
<div><span style="font-size: 10pt;">Was a bug introduced in LLDB? Or is our use of DWARF expressions to retrieve the return address not "standards compliant"?</span></div>
<div><br>
</div>
<div>Thanks,</div>
<div>-Philippe</div>
<div><br>
</div>
</div>
</body>
</html>