On Oct 7, 2013, at 4:33 PM, Michael Sartain <[email protected]> wrote:
> On Mon, Oct 7, 2013 at 4:13 PM, Greg Clayton <[email protected]> wrote: > Looks good. > > More comments below... > On Oct 1, 2013, at 12:16 PM, Michael Sartain <[email protected]> wrote: > > > On Fri, Sep 13, 2013 at 11:33 AM, Thirumurthi, Ashok > > <[email protected]> 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 _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
