[lldb-dev] lldb test failures on 32bit

[Kaylor, Andrew]

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:mikesart at gmail.com]
Sent: Thursday, August 15, 2013 1:07 PM
To: Greg Clayton; Kaylor, Andrew
Cc: lldb-dev at cs.uiuc.edu
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 <mikesart at gmail.com<mailto:mikesart at gmail.com>> wrote:
On Tue, Aug 13, 2013 at 6:22 PM, Michael Sartain <mikesart at gmail.com<mailto:mikesart at gmail.com>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20130816/64f349de/attachment.html>