[Lldb-commits] [PATCH] D62221: [lldb-server][LLGS] Support 'g' packets

Wed May 22 21:48:57 PDT 2019

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  <guiandrade at 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 <reviews at 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 |  guiandrade at google.com |  Google Waterloo, Canada(https://careers.google.com/locations/waterloo/) 
> 
> 
<signatureafterquotedtext></signatureafterquotedtext>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20190522/51aadfa4/attachment.html>