[lldb-dev] RegisterContextPOSIX_i386

[Greg Clayton]

On Oct 7, 2013, at 4:33 PM, Michael Sartain <mikesart at gmail.com> wrote:

> 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?

Sure thing.

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

The way I see this happening on LLDB is to be allowed to give a snippet of code that describes the register as a type. We then take this and parse it with the expression parser and then display the variable using this type.

So we could have a code snippet like:

'''
struct XMMValue {
    union float32 { float floats[4]; };
    union float64 { double doubles[2]; }
    ...
};
'''

Then the qRegisterInfo packets could specify the type of the register with: "display-type:XMMValue;". The code snippet above could also contain enumerations and other types to make the display of registers more clear. Something for the ARM CPSR register could be:


'''
enum Mode {
 User = 0x10,
 FIQ = 0x11,
 IRQ = 0x12,
 Supervisor = 0x13,
 Abort = 0x17,
 Undefined = 0x1b,
 System = 0x1f
};

struct CPSR {
   ... 
   Mode mode;
}
'''


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

So the above code snippets could be supplied by the register context plug-ins and parsed into the target's scratch AST and then used for registers. They should probably be hidden in a namespace or something to avoid collisions with the user code.


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