[lldb-dev] lldb test failures on 32bit

[Kaylor, Andrew]

OK.  It seems like whatever generated that sh_entsize value for i386 is wrong, but I suppose it's best to handle it as you have anyway.

The only problem I see with your patch is that according to the ELF spec zero is a valid value for sh_addralign, and if you pass that to llvm::RoundUpToAlignment it will get a divide-by-zero error.  If you check for zero and substitute 1 in that case it should be good to commit.

-Andy

From: Michael Sartain [mailto:mikesart at gmail.com]
Sent: Friday, August 16, 2013 4:35 PM
To: Kaylor, Andrew
Cc: Greg Clayton; lldb-dev at cs.uiuc.edu
Subject: Re: lldb test failures on 32bit

> 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(%7b%7d,%20'cvml',%20'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(%7b%7d,%20'cvml',%20'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 : "??");
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20130816/cf3e38ca/attachment.html>