<div dir="ltr"><div>On Fri, Aug 23, 2013 at 7:59 AM, Thirumurthi, Ashok <<a href="mailto:ashok.thirumurthi@intel.com">ashok.thirumurthi@intel.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

FYI, the x86_64 build of LLDB will have limited success with i386 inferiors, but it’s a pretty good starting point (i.e. test/functionalities/registers passes).  In this case, ptrace calls populate the 64-bit register set, and the RegisterContext_x86_64 class uses offsetof to associate the i386 register set with the LS bytes of the associated 64-bit registers.  However, this isn’t correct because “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. – Greg Clayton”.<br>

</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

The i386 build of LLDB should use RegisterContext_i386.  Similarly, a future remote i386 target should use RegisterContext_i386.  However, this class is just stubbed in.</blockquote><div><br></div><div>We're currently using PTRACE_GETREGS in ProcessMonitor which (as has been pointed out) always returns the 64-bit register structure if called from a 64-bit debugger even if the target is 32-bit. This is why the RegisterContextPOSIX code is based on host::arch and tries to do the 64 <-> 32 bit register conversion jig.</div>

<div><br></div><div>In 2.6.34, PTRACE_GETREGSET support was committed which allows us to get the correctly sized register set information. Checkin information is down below. (I also wrote a test ptrace program and it does appear to work.) We're already using PTRACE_GETREGSET elsewhere, so I think this requirement should be fine and switching to this should give us the correct 32-bit registers for 32-bit debuggee with a 64-bit debugger:</div>

<div><div><br></div><div>    ptrace(PTRACE_GETREGSET, child, NT_PRSTATUS, &regs_vec);</div></div><div><br></div><div>The RegisterContextPOSIX_i386 code is fairly sparse right now. There is no core file or watchpoint support, etc.</div>

<div><br></div><div>And now my question. :) Does this plan make sense?</div><div> 1. Copy all the x64 register context posix files over to i386. (Ie, RegisterContextPOSIX_x86_64.* --> RegisterContextPOSIX_i386.*, etc)</div>

<div> 2. Remove the 32-bit register conversion code in the 64-bit code.</div><div> 3. Remove the 64-bit registers, etc. from the 32-bit code.</div><div> 4. Modify POSIXThread::GetRegisterContext() to check the debuggee architecture instead of the host.</div>

<div><br></div><div>Any feedback or pointers before I start tackling this would be great. Thanks!</div><div> -Mike</div><div><br></div><div>---------------</div><div><div>commit 2225a122ae26d542bdce523d9d87a4a7ba10e07b</div>

<div>Author: Suresh Siddha <<a href="mailto:suresh.b.siddha@intel.com">suresh.b.siddha@intel.com</a>></div><div>Date:   Thu Feb 11 11:51:00 2010 -0800</div><div><br></div><div>    ptrace: Add support for generic PTRACE_GETREGSET/PTRACE_SETREGSET</div>

<div>    </div><div>    Generic support for PTRACE_GETREGSET/PTRACE_SETREGSET commands which</div><div>    export the regsets supported by each architecture using the correponding</div><div>    NT_* types. These NT_* types are already part of the userland ABI, used</div>

<div>    in representing the architecture specific register sets as different NOTES</div><div>    in an ELF core file.</div><div>    </div><div>    'addr' parameter for the ptrace system call encode the REGSET type (using</div>

<div>    the corresppnding NT_* type) and the 'data' parameter points to the</div><div>    struct iovec having the user buffer and the length of that buffer.</div><div>    </div><div>        struct iovec iov = { buf, len};</div>

<div>        ret = ptrace(PTRACE_GETREGSET/PTRACE_SETREGSET, pid, NT_XXX_TYPE, &iov);</div><div>    </div><div>    On successful completion, iov.len will be updated by the kernel specifying</div><div>    how much the kernel has written/read to/from the user's iov.buf.</div>

<div>    </div><div>    x86 extended state registers are primarily exported using this interface.</div><div>    </div><div>    Signed-off-by: Suresh Siddha <<a href="mailto:suresh.b.siddha@intel.com">suresh.b.siddha@intel.com</a>></div>

<div>    LKML-Reference: <<a href="mailto:20100211195614.886724710@sbs-t61.sc.intel.com">20100211195614.886724710@sbs-t61.sc.intel.com</a>></div><div>    Acked-by: Hongjiu Lu <<a href="mailto:hjl.tools@gmail.com">hjl.tools@gmail.com</a>></div>

<div>    Cc: Roland McGrath <<a href="mailto:roland@redhat.com">roland@redhat.com</a>></div><div>    Signed-off-by: H. Peter Anvin <<a href="mailto:hpa@zytor.com">hpa@zytor.com</a>></div></div><div><br></div>
</div>