On Sep 12, 2013, at 5:58 PM, Michael Sartain <mikes...@gmail.com> wrote:
> On Fri, Aug 23, 2013 at 7:59 AM, Thirumurthi, Ashok
> <ashok.thirumur...@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, ®s_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.
Sounds correct to me. Just be sure to convert the correct register numbers for
the 32 bit stuff (which you probably already have for 32 bit on 64 bit
machines). The biggest issue to watch out for is the register numbers for ESP
and EBP. They are reversed between the DWARF and GCC register numbers.
>
> Any feedback or pointers before I start tackling this would be great. Thanks!
> -Mike
>
> ---------------
> commit 2225a122ae26d542bdce523d9d87a4a7ba10e07b
> Author: Suresh Siddha <suresh.b.sid...@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.sid...@intel.com>
> LKML-Reference: <20100211195614.886724...@sbs-t61.sc.intel.com>
> Acked-by: Hongjiu Lu <hjl.to...@gmail.com>
> Cc: Roland McGrath <rol...@redhat.com>
> Signed-off-by: H. Peter Anvin <h...@zytor.com>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
