<div dir="ltr">On Mon, Oct 7, 2013 at 4:13 PM, Greg Clayton <span dir="ltr"><<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Looks good.<br>
<br>
More comments below...<br>
<div class="im">On Oct 1, 2013, at 12:16 PM, Michael Sartain <<a href="mailto:mikesart@gmail.com">mikesart@gmail.com</a>> wrote:<br>
<br>
> On Fri, Sep 13, 2013 at 11:33 AM, Thirumurthi, Ashok <<a href="mailto:ashok.thirumurthi@intel.com">ashok.thirumurthi@intel.com</a>> wrote:<br>
> 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.<br>
><br>
> Here is a first pass at this:<br>
><br>
> <a href="http://llvm-reviews.chandlerc.com/D1798" target="_blank">http://llvm-reviews.chandlerc.com/D1798</a><br>
><br>
> It passes all the 64-bit linux tests, although there is still a bit of cleanup I need to do.<br>
> - FreeBSD is most likely busted... (I'll contact Ed about working on this when it's a bit more nailed down.)<br>
> - I need to check and fix dwarf / gdb constant values.<br>
> - I don't like the ConvertRegisterKindToRegisterNumber() routines.<br>
<br>
</div>Do you not like how they are implemented in the register context classes for posix/linux/freebsd, or are you questioning their need?<br>
<br>
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.</blockquote>
<div><br></div><div>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.</div>
<div><br></div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">
> - Also don't like the RegisterContextPOSIXProcessMonitor_x86_64::ReadRegister() / WriteRegister() routines.<br>
<br>
</div>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).<br>
</blockquote><div><br></div><div>This is good information also.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">> - Need to implement RegisterContextPOSIX_i386* so 32-bit LLDB will fully work. (This may come in a second checkin).<br>
> - Would love to have xmm00, xmm01, etc. type aliases for mmx, sse, and avx registers.<br>
<br>
</div>Is this more than filling out the "alt_name" field? Or is this more like the "eax" register that is part of "rax"?<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>(gdb) p $xmm0<br></div><div>$1 = {</div><div> v4_float = {9.14767638e-41,</div><div> 0,</div><div> 0,</div><div> 0},</div><div> v2_double = {3.2252605360516574e-319,</div><div> 0},</div>
<div> v16_int8 = {0,</div><div> -1,</div><div> 0 <repeats 14 times>},</div><div> v8_int16 = {-256,</div><div> 0,</div><div> 0,</div><div> 0,</div><div> 0,</div><div> 0,</div><div> 0,</div>
<div> 0},</div><div> v4_int32 = {65280,</div><div> 0,</div><div> 0,</div><div> 0},</div><div> v2_int64 = {65280,</div><div> 0},</div><div> uint128 = 65280</div><div>}</div><div> </div><div><div>
gdb also does this for the flag registers:</div>
<div><br></div><div>eflags 0x202 [ IF ]<br></div><div>mxcsr 0x1f80 [ IM DM ZM OM UM PM ]<br></div><div><br></div><div>Which can be quite useful.</div></div><div><br></div><div>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.</div>
<div><br></div><div>Thanks for the help Greg.</div><div> -Mike</div></div></div></div>