<div dir="ltr"><div>I realized Andrew's reloc-fix-32.patch & stack-fix-32.patch weren't checked in and I didn't have them. Applying both of those with my patch below allows me to step over the 32-bit printf() calls now.</div>
<div><br></div><div>Are those patches what you hope to check in at some point Andrew?</div><div><br></div><div>And please let me know if it's ok to check this in:</div><div><br></div><div><a href="http://llvm-reviews.chandlerc.com/D1189" target="_blank">http://llvm-reviews.chandlerc.com/D1189</a><br>
</div><div><br></div><div>Thanks!</div><div> -Mike</div><div><br></div>On Thu, Aug 15, 2013 at 10:39 AM, Michael Sartain <span dir="ltr"><<a href="mailto:mikesart@gmail.com" target="_blank">mikesart@gmail.com</a>></span> wrote:<br>
<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">
<div class="im">On Tue, Aug 13, 2013 at 6:22 PM, Michael Sartain <span dir="ltr"><<a href="mailto:mikesart@gmail.com" target="_blank">mikesart@gmail.com</a>></span> wrote:<br></div><div class="gmail_extra"><div class="gmail_quote">
<div class="im">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>Unwind info does exist for addresses in main(), and all of this works as expected in x64.<br>
</div><div><div><div><div class="gmail_extra"><div class="gmail_extra"><br></div><div class="gmail_extra">I'll start debugging where this is failing...</div></div></div></div></div></div></blockquote><div><br></div></div>
<div>
For x86 elf files, the plt_entsize wasn't being rounded to the proper alignment - this was causing the .plt symbols to be incorrect, along with unwind info, etc. This patch fixes that:</div><div><br></div><div><a href="http://llvm-reviews.chandlerc.com/D1189" target="_blank">http://llvm-reviews.chandlerc.com/D1189</a><br>
</div><div><br></div><div>The next problem is we're using the x64 register set, but then calling into the i386 ABI. Ie, this call:<br></div><div><br></div><div><div> 246| addr_t pc;</div><div> 247+> if (!ReadGPRValue (eRegisterKindGeneric, LLDB_REGNUM_GENERIC_PC, pc))</div>
<div> 248| {</div></div><div><br></div><div>Winds up here:</div><div><br></div><div><div>1092| ExecutionContext exe_ctx(m_thread.shared_from_this());</div><div>1093| Process *process = exe_ctx.GetProcessPtr();</div>
<div>1094| if (have_unwindplan_regloc == false)</div><div>1095| {</div><div>1096| // If a volatile register is being requested, we don't want to forward the next frame's register contents</div><div>
1097| // up the stack -- the register is not retrievable at this frame.</div><div>1098| ABI *abi = process ? process->GetABI().get() : NULL;</div><div>1099| if (abi)</div><div>1100| {</div>
<div>1101+> const RegisterInfo *reg_info = GetRegisterInfoAtIndex(lldb_regnum);</div><div>1102| if (reg_info && abi->RegisterIsVolatile (reg_info))</div><div>1103| {</div>
<div>
1104| UnwindLogMsg ("did not supply reg location for %d (%s) because it is volatile",</div><div>1105| lldb_regnum, reg_info->name ? reg_info->name : "??");</div>
<div>1106| return UnwindLLDB::RegisterSearchResult::eRegisterIsVolatile;</div><div>1107| }</div><div>1108| }</div></div><div><br></div><div>Which calls into this function:</div><div><br>
</div><div><div><div>902| bool</div><div>903| ABIMacOSX_i386::RegisterIsCalleeSaved (const RegisterInfo *reg_info)</div><div>904| {</div><div>905| if (reg_info)</div><div>906| {</div><div>907| // Saved registers are ebx, ebp, esi, edi, esp, eip</div>
</div><div><div>908| const char *name = reg_info->name;</div><div>909| if (name[0] == 'e')</div><div>910| {</div></div></div><div><br></div><div>reg_info->name is "rip", and so ABIMacOSX_i386::RegisterIsCalleeSaved() is returning false.</div>
<div><br></div><div>ABIMacOSX_i386.cpp looks like it does several things using register names.<br></div><div class="im"><div><br></div><div><span style="font-family:arial,sans-serif;font-size:13px">> Actually, RegisterContext_i386 doesn't get used in the case of a 32-bit inferior on a 64-bit host. In that scenario we use RegisterContext_x86_64 and do some mapping under the covers for 32-bit targets.</span><br>
</div><div><br></div></div><div>Does this mean this is an issue with RegisterContext_x86_64 returning "rip" and not "eip"?</div><div><br></div><div>Thanks.</div><div> -Mike</div></div></div></div>
</blockquote></div><br></div></div>