[lldb-dev] lldb test failures on 32bit

[Michael Sartain]

> As for your patch, am I correct in thinking that I should ignore the
history in that review?

Yeah, sorry. I need to clear arc out.

> Can you explain the change to me?  What values were you seeing for
sh_entsize and sh_addralign?

On x64, both were 16. On i386, entsize was 4, addralign was 16. The size of
the .plt entries are 16 in each case.

Thanks!

On Friday, August 16, 2013, Kaylor, Andrew wrote:

>  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 <javascript:_e({},
> 'cvml', 'mikesart at gmail.com');>]
> *Sent:* Thursday, August 15, 2013 1:07 PM
> *To:* Greg Clayton; Kaylor, Andrew
> *Cc:* lldb-dev at cs.uiuc.edu <javascript:_e({}, 'cvml',
> '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>
> wrote:****
>
>  On Tue, Aug 13, 2013 at 6:22 PM, Michael Sartain <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 :
> "??");****
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20130816/9d84b7e1/attachment.html>