If the remote serial protocol stub includes the GPR register values in the stop packet / jThreadsInfo packet, lldb will pre-seed the thread's RegisterContext with these values. So if the user asks for rax, lldb will already have rax for instance. debugserver doesn't send the vector/floating point register for instance, so if someone monitors xmm0, lldb would need to request xmm0 after every step if debugserver was the remote serial protocol agent. <signaturebeforequotedtext></signaturebeforequotedtext> On 05/22/19 06:30 PM, Guilherme Andrade <guiandr...@google.com> wrote: > > > > Thank you for the suggestion, Jason! The feature is like this > https://docs.microsoft.com/en-us/visualstudio/debugger/how-to-use-the-registers-window?view=vs-2019 > - the user can select the register sets they want to see. There's an extra > complication, though. I am using the C++ API, so I actually get the registers > by calling SBFrame::GetRegisters(), and as I start retrieving their fields, > the `p` packets are lazily exchanged. Do you know if there is a way to get > their values up front from that API, or a way to modify that lazy behavior? > > > > > On Wed, May 22, 2019 at 8:59 PM Jason Molenda via Phabricator > <revi...@reviews.llvm.org> wrote: > > > jasonmolenda added a comment. > > > > Does your feature print *all* the registers including floating point/vector > > registers? Or just the main general purpose registers? In debugserver, we > > expedite the register values for the stopping thread: > > > > 1558572448.355979919 < 624> read packet: > > $T05thread:3ef471;threads:3ef471;thread-pcs:10001e939;00:d803000000000000;01:0080536cff7f0000;02:d803000000000000;03:b0e0bfeffe7f0000;04:0000000000000000;05:2900000000000000;06:a0e2bfeffe7f0000;07:a8e0bfeffe7f0000;08:0000000000000000;09:0000000000000000;0a:0000000000000000;0b:0000000000000000;0c:00e2bfeffe7f0000;0d:b0e2bfeffe7f0000;0e:0000000000000000;0f:2900000000000000;10:39e9010001000000;11:4602000000000000;12:2b00000000000000;13:0000000000000000;14:0000000000000000;metype:6;mecount:2;medata:2;medata:0;memory:0x7ffeefbfe2a0=10e7bfeffe7f000006528a6dff7f0000;memory:0x7ffeefbfe710=40e7bfeffe7f000086838b6dff7f0000;#00 > > > > because the cost of sending all the register values every time is > > miniscule. When we are at a "public stop" (visible to the user), we may > > need to get information about *all* the threads - for this, we use the > > JSON-formatted jThreadsInfo packet which gives you the GPR register values > > for every thread (in this example, there is only one thread) - > > > > 1558572448.379079103 < 16> send packet: $jThreadsInfo#c1 > > 1558572448.379371881 <1609> read packet: > > $[{"tid":4125809,"metype":6,"medata":[2,0],"reason":"exception","qaddr":4295855808,"associated_with_dispatch_queue":true,"dispatch_queue_t":140735794523072,"qname":"com.apple.main-thread","qkind":"serial","qserialnum":1,"registers":{"0":"0000000000000000","1":"c0f9bfeffe7f0000","2":"0200000000000000","3":"1000000000000000","4":"0006000000000000","5":"d34c566cff7f0000","6":"50e5bfeffe7f0000","7":"f8e4bfeffe7f0000","8":"4400000000000000","9":"4002000000000000","10":"03000000ffffffff","11":"4602000000000000","12":"583a566cff7f0000","13":"753a566cff7f0000","14":"0000000000000000","15":"0000000000000000","16":"66b7a56dff7f0000","17":"4602000000000000","18":"2b00000000000000","19":"0000000000000000","20":"0000000000000000"}],"memory":[{"address":140732920751440,"bytes":"80e5bfeffe7f000032d0846dff7f0000"}],{"address":140732920751488,"bytes":"a0e5bfeffe7f0000f490856dff7f0000"}],{"address":140732920751520,"bytes":"d0e5bfeffe7f000091e7766aff7f0000"}],{"address":140732920751568,"bytes":"70e6bfeffe7f0000fe15896dff7f0000"}],{"address":140732920751728,"bytes":"b0e6bfeffe7f0000de14896dff7f0000"}],{"address":140732920751792,"bytes":"10e7bfeffe7f0000fd7e8a6dff7f0000"}],{"address":140732920751888,"bytes":"40e7bfeffe7f0000cf838b6dff7f0000"}],{"address":140732920751936,"bytes":"d0edbfeffe7f00009869010001000000"}],{"address":140732920753616,"bytes":"40f7bfeffe7f00003a40010001000000"}],{"address":140732920756032,"bytes":"60f8bfeffe7f000027e2000001000000"}],{"address":140732920756320,"bytes":"88f8bfeffe7f000025e0000001000000"}],{"address":140732920756360,"bytes":"00000000000000000100000000000000"}]]}]]#00 > > > > I think for your use case, having lldb-server provide all the values up > > front (if it isn't already) is the approach you should take. > > > > (the only thing that's might be unexpected is that the register values & > > memory data are sent as *strings* - JSON only represents numbers in base10; > > this is sending the register & memory data in target-endian order, little > > endian here, in the hex-bytes strings.) > > > > > > Repository: > > rG LLVM Github Monorepo > > > > CHANGES SINCE LAST ACTION > > https://reviews.llvm.org/D62221/new/ > > > > https://reviews.llvm.org/D62221 > > > > > > > > > > -- > > > > Guilherme Andrade | Software Engineer | guiandr...@google.com | Google > Waterloo, Canada(https://careers.google.com/locations/waterloo/) > > <signatureafterquotedtext></signatureafterquotedtext>
_______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
