[lldb-dev] lldb test failures on 32bit
andrew.kaylor at intel.com
Fri Aug 16 16:49:52 PDT 2013
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.
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.
On Friday, August 16, 2013, Kaylor, Andrew wrote:
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?
Sent: Thursday, August 15, 2013 1:07 PM
To: Greg Clayton; Kaylor, Andrew
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:
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:
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))
Winds up here:
1092| ExecutionContext exe_ctx(m_thread.shared_from_this());
1093| Process *process = exe_ctx.GetProcessPtr();
1094| if (have_unwindplan_regloc == false)
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)
1101+> const RegisterInfo *reg_info = GetRegisterInfoAtIndex(lldb_regnum);
1102| if (reg_info && abi->RegisterIsVolatile (reg_info))
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...
More information about the lldb-dev