[lldb-dev] RegisterContextPOSIX_i386

[Michael Sartain]

On Mon, Oct 7, 2013 at 4:13 PM, Greg Clayton <gclayton at apple.com> wrote:

> Looks good.
>
> More comments below...
> On Oct 1, 2013, at 12:16 PM, Michael Sartain <mikesart at gmail.com> wrote:
>
> > On Fri, Sep 13, 2013 at 11:33 AM, Thirumurthi, Ashok <
> ashok.thirumurthi at intel.com> wrote:
> > One point to consider is if there is scope for some common code between
> architectures.  Note that the list of architectures will only grow (i.e.
> x32).  A future point is to keep POSIX-isms nicely contained.  When
> considering platform-independent remote debugging that is consistent with
> native-local debugging, we'll want code consistent between platforms to
> live in one place.
> >
> > Here is a first pass at this:
> >
> > http://llvm-reviews.chandlerc.com/D1798
> >
> > It passes all the 64-bit linux tests, although there is still a bit of
> cleanup I need to do.
> >  - FreeBSD is most likely busted... (I'll contact Ed about working on
> this when it's a bit more nailed down.)
> >  - I need to check and fix dwarf / gdb constant values.
> >  - I don't like the ConvertRegisterKindToRegisterNumber() routines.
>
> Do you not like how they are implemented in the register context classes
> for posix/linux/freebsd, or are you questioning their need?
>
> They are needed for parsing DWARF and EH frame information and any other
> object file sections that contain register numbers in them. We can probably
> automate the ConvertRegisterKindToRegisterNumber() up into the
> RegisterContext base class so that it uses the RegisterInfo data to
> populate lookup tables, but then we might need a finalize call to let the
> base class know that it is ok to go ahead and compute the lookup tables.


I didn't like how they were implemented with the architecture switch
statement and then two fairly large individual register name case
statements. I fixed that in "diff 3 & 4" up on the chandlerc site.

I'm glad I said that though - your description of how they are utilized is
quite useful. Ok if I put that in as a code comment above those routines?


>  >  - Also don't like the
> RegisterContextPOSIXProcessMonitor_x86_64::ReadRegister() / WriteRegister()
> routines.
>
> Again, do you not like how they are implemented, or would you rather see
> them go away? I tried to add flexibility to the register contexts so you
> can read/write all registers at once, or read/write single registers since
> things like GDB remote might support one, the other, or both. Many JTAG
> debuggers also read/write registers individually and it can impose quite a
> performance penalty to force reading/writing all registers at once (all
> GPRs, all FPUs, etc).
>

This is good information also.


> >  - Need to implement RegisterContextPOSIX_i386* so 32-bit LLDB will
> fully work. (This may come in a second checkin).
> >  - Would love to have xmm00, xmm01, etc. type aliases for mmx, sse, and
> avx registers.
>
> Is this more than filling out the "alt_name" field? Or is this more like
> the "eax" register that is part of "rax"?
>

It would be more eax part of rax type thing. A more general question is how
do folks look at these SSE and AVX registers on lldb? On gdb, we get
something like this by default. I haven't found an easy way to view these
registers like that with lldb - I'm probably missing something though.

(gdb) p $xmm0
$1 = {
  v4_float =     {9.14767638e-41,
    0,
    0,
    0},
  v2_double =     {3.2252605360516574e-319,
    0},
  v16_int8 =     {0,
    -1,
    0 <repeats 14 times>},
  v8_int16 =     {-256,
    0,
    0,
    0,
    0,
    0,
    0,
    0},
  v4_int32 =     {65280,
    0,
    0,
    0},
  v2_int64 =     {65280,
    0},
  uint128 = 65280
}

gdb also does this for the flag registers:

eflags         0x202    [ IF ]
mxcsr          0x1f80   [ IM DM ZM OM UM PM ]

Which can be quite useful.

I'm having trouble getting FreeBSD to build at the moment and am working
with Ed on that. As soon as I get things verified there, I'll check this in.

Thanks for the help Greg.
 -Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20131007/71361411/attachment.html>