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? > > - 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
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
