[lldb-dev] lldb test failures on 32bit

[Kaylor, Andrew]

The x86_64 register context attempts to remap the registers on the fly when we're debugging a 32-bit target.

There is a problem in ConvertBetweenRegisterKinds where this can return the incorrect result (because it returns the first match and ignores the target).

I have a patch that adds a special case to handle that if the target kind is eRegisterKindLLDB, but I don't think that's in trunk yet.  I suspect that the conversion will fail for other register kinds too, but that's the only one we've seen.

I think we need to put a short-term fix like that in place until we have time to re-work the i386 register context.

-Andy


-----Original Message-----
From: Greg Clayton [mailto:gclayton at apple.com] 
Sent: Monday, August 19, 2013 5:45 PM
To: Kaylor, Andrew
Cc: Michael Sartain; lldb-dev at cs.uiuc.edu
Subject: Re: lldb test failures on 32bit

The one remaining big issue we still have is we are using the x86_64 register context that waters itself down for i386. The DWARF and GCC register numbers need to use the i386 register numbering schemes otherwise all info parsed from EH frame and DWARF will be incorrect when they don't match up. Is this fixed already, or does it still need to be fixed?


On Aug 16, 2013, at 4:49 PM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote:

> 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] 
> 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> 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 : "??");
>