[lldb-dev] RegisterContextPOSIX_i386

[Michael Sartain]

On Fri, Aug 23, 2013 at 7:59 AM, Thirumurthi, Ashok <
ashok.thirumurthi at intel.com> wrote:

> 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”.
>


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.


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.

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:

    ptrace(PTRACE_GETREGSET, child, NT_PRSTATUS, &regs_vec);

The RegisterContextPOSIX_i386 code is fairly sparse right now. There is no
core file or watchpoint support, etc.

And now my question. :) Does this plan make sense?
 1. Copy all the x64 register context posix files over to i386. (Ie,
RegisterContextPOSIX_x86_64.* --> RegisterContextPOSIX_i386.*, etc)
 2. Remove the 32-bit register conversion code in the 64-bit code.
 3. Remove the 64-bit registers, etc. from the 32-bit code.
 4. Modify POSIXThread::GetRegisterContext() to check the debuggee
architecture instead of the host.

Any feedback or pointers before I start tackling this would be great.
Thanks!
 -Mike

---------------
commit 2225a122ae26d542bdce523d9d87a4a7ba10e07b
Author: Suresh Siddha <suresh.b.siddha at intel.com>
Date:   Thu Feb 11 11:51:00 2010 -0800

    ptrace: Add support for generic PTRACE_GETREGSET/PTRACE_SETREGSET

    Generic support for PTRACE_GETREGSET/PTRACE_SETREGSET commands which
    export the regsets supported by each architecture using the correponding
    NT_* types. These NT_* types are already part of the userland ABI, used
    in representing the architecture specific register sets as different
NOTES
    in an ELF core file.

    'addr' parameter for the ptrace system call encode the REGSET type
(using
    the corresppnding NT_* type) and the 'data' parameter points to the
    struct iovec having the user buffer and the length of that buffer.

        struct iovec iov = { buf, len};
        ret = ptrace(PTRACE_GETREGSET/PTRACE_SETREGSET, pid, NT_XXX_TYPE,
&iov);

    On successful completion, iov.len will be updated by the kernel
specifying
    how much the kernel has written/read to/from the user's iov.buf.

    x86 extended state registers are primarily exported using this
interface.

    Signed-off-by: Suresh Siddha <suresh.b.siddha at intel.com>
    LKML-Reference: <20100211195614.886724710 at sbs-t61.sc.intel.com>
    Acked-by: Hongjiu Lu <hjl.tools at gmail.com>
    Cc: Roland McGrath <roland at redhat.com>
    Signed-off-by: H. Peter Anvin <hpa at zytor.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20130912/6ddbfd2e/attachment.html>