Hi Mike, A variation of reloc-fix-32.patch was committed today by Richard Mitton.
I need to do something with stack-fix-32.patch. If I'm reading the documentation correctly, it appears that stack frames really do need to be 8-byte aligned in Darwin even for 32-bit code. Unfortunately, we're using the same ABI plugin for 32-bit x86 code on Darwin and Linux and at the level where this check is performed we don't know which we're looking at. As far as I know, there really isn't a significant difference between the two scenarios, so I don't think we'd want a totally separate ABI plug-in. I just need to see if there's an easy way to give it a little target information when it's created so it can handle the special cases. As for your patch, am I correct in thinking that I should ignore the history in that review? Can you explain the change to me? What values were you seeing for sh_entsize and sh_addralign? -Andy From: Michael Sartain [mailto:[email protected]] Sent: Thursday, August 15, 2013 1:07 PM To: Greg Clayton; Kaylor, Andrew Cc: [email protected] Subject: Re: [lldb-dev] lldb test failures on 32bit 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. Are those patches what you hope to check in at some point Andrew? And please let me know if it's ok to check this in: http://llvm-reviews.chandlerc.com/D1189 Thanks! -Mike On Thu, Aug 15, 2013 at 10:39 AM, Michael Sartain <[email protected]<mailto:[email protected]>> wrote: On Tue, Aug 13, 2013 at 6:22 PM, Michael Sartain <[email protected]<mailto:[email protected]>> wrote: Unwind info does exist for addresses in main(), and all of this works as expected in x64. I'll start debugging where this is failing... 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: http://llvm-reviews.chandlerc.com/D1189 The next problem is we're using the x64 register set, but then calling into the i386 ABI. Ie, this call: 246| addr_t pc; 247+> if (!ReadGPRValue (eRegisterKindGeneric, LLDB_REGNUM_GENERIC_PC, pc)) 248| { Winds up here: 1092| ExecutionContext exe_ctx(m_thread.shared_from_this()); 1093| Process *process = exe_ctx.GetProcessPtr(); 1094| if (have_unwindplan_regloc == false) 1095| { 1096| // If a volatile register is being requested, we don't want to forward the next frame's register contents 1097| // up the stack -- the register is not retrievable at this frame. 1098| ABI *abi = process ? process->GetABI().get() : NULL; 1099| if (abi) 1100| { 1101+> const RegisterInfo *reg_info = GetRegisterInfoAtIndex(lldb_regnum); 1102| if (reg_info && abi->RegisterIsVolatile (reg_info)) 1103| { 1104| UnwindLogMsg ("did not supply reg location for %d (%s) because it is volatile", 1105| lldb_regnum, reg_info->name ? reg_info->name : "??"); 1106| return UnwindLLDB::RegisterSearchResult::eRegisterIsVolatile; 1107| } 1108| } Which calls into this function: 902| bool 903| ABIMacOSX_i386::RegisterIsCalleeSaved (const RegisterInfo *reg_info) 904| { 905| if (reg_info) 906| { 907| // Saved registers are ebx, ebp, esi, edi, esp, eip 908| const char *name = reg_info->name; 909| if (name[0] == 'e') 910| { reg_info->name is "rip", and so ABIMacOSX_i386::RegisterIsCalleeSaved() is returning false. ABIMacOSX_i386.cpp looks like it does several things using register names. > 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. Does this mean this is an issue with RegisterContext_x86_64 returning "rip" and not "eip"? Thanks. -Mike
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
