Ping. There are 2 patches in this series waiting review. Thanks, Abid
> -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Abid, Hafiz > Sent: 09 October 2013 17:33 > To: [email protected] > Subject: Re: [lldb-dev] LLDB and gdbserver > > Hi All, > The attached patch implements reading register description of the remote > target from the xml file. The path of the file is provided through a settings > as > a first step. We can make lldb search though xml files and find correct one > based on arch and g packet size on top of this patch. After this patch and my > previous patch (regarding adjusting pc when breakpoint is hit) go in, we can > connect to gdbserver like shown below. I am also attaching an xml file that I > used for testing on Ubuntu 12.04 on x86-64. > > I was not aware what will be the best way to check for the presence of > libXML. I am using an already present macro 'CLANG_HAVE_LIBXML'. > > How does it all look? > > Regards, > Abid > > lldb ~/demos/act > Current executable set to '/home/abidh/demos/act' (x86_64). > (lldb) settings set -- plugin.process.gdb-remote.register-definition-file > /home/abidh/work/llvm/src/tools/lldb/xml/x86_64_gdbserver.xml > (lldb) setting set -- plugin.process.gdb-remote.adjust-breakpoint-pc 1 > (lldb) gdb-remote 10000 > > > > -----Original Message----- > > From: [email protected] > > [mailto:[email protected]] > > On Behalf Of Abid, Hafiz > > Sent: 04 October 2013 17:45 > > To: Greg Clayton > > Cc: [email protected] > > Subject: Re: [lldb-dev] LLDB and gdbserver > > > > Hi Greg, > > I am attaching a patch that implements the 2nd part as discussed below > i.e. > > to adjust the pc after hitting breakpoint. The response of qHostInfo > > packet is checked for ' adjusts_breakpoint_pc' key. If found, it gives > > the value by which the pc should be adjusted. In its absence, a new > > setting ' plugin.process.gdb- remote .adjust-breakpoint-pc' can be > > used to provide this information. The default of this settings is 0. > > If a user is connecting to a stub that needs the debugger to adjust > > the pc (e.g. gdbserver) then user can adjust the value of this settings > accordingly. > > > > I tested the new setting and it is working fine. As I don't have a > > stub that sends qHostInfo with this new key, so that code is un-tested. OK > to commit? > > > > Regards, > > Abid > > > > > -----Original Message----- > > > From: Greg Clayton [mailto:[email protected]] > > > Sent: 05 September 2013 19:26 > > > To: Abid, Hafiz > > > Cc: [email protected] > > > Subject: Re: [lldb-dev] LLDB and gdbserver > > > > > > > > > On Sep 5, 2013, at 9:16 AM, Abid, Hafiz <[email protected]> > wrote: > > > > > > > I was able to make the LLDB work with gdbserver. Running, > > > > stopping, > > > source stepping were working ok. I needed to patch 2 areas to make > > > it > > work. > > > I would like comments on those changes before I can get them ready > > > for submission. > > > > > > > > If dynamic register info is not available then > > > > GDBRemoteRegisterContext is > > > relying on hardcoded registers for ARM. I have to added similar > > > hard-coded registers for x86_64. Would it make any sense if we keep > > > GDBRemoteRegisterContext for reading/writing the register packets only. > > > The task of translating those packets should be left to some higher > > > level classes. Perhaps something like GDBRemoteRegisterContext_arm, > > > GDBRemoteRegisterContext_x86_64 etc. Or for the time being, > > > hardcoding is considered ok. > > > > > > The only hard coded registers should be for ARM as this was needed > > > for legacy iOS support. Any new registers should use a new plugin > > > setting that supplies an XML file that describes the registers. The > > > setting should be something like: > > > > > > (lldb) settings set > > > plugin.process.gdb-remote.register-definition-file > > > /path/to/registers.xml > > > > > > The XML register description should supply the same information as > > > the qRegisterInfo packet for all registers. Then the > > > GDBRemoteDynamicRegisterInfo class will need to be able to set > > > itself up using an XML file. Another way to do this would be to > > > supply a python > > file. > > > We have Python bridging objects available where you could easily > > > make a new python callback where a python dictionary could be > returned. > > > Python might also be more useful because you could create classes > > > that know the common register numbers for certain architectures and > ABIs... > > > > > > So the flow would be: > > > - debugging starts with debugserver > > > - we stop for the first time and "qRegisterInfo0" packet is sent, > > > and the unsupported response of "$#00" is returned. > > > - we grab the value of the > > > "plugin.process.gdb-remote.register-definition- > > > file" setting, and if it is set, we parse that file > > > - else fallback to hard coded registers. > > > > > > So I would avoid adding anymore hard coded registers to LLDB > > > otherwise we will end up with a mess in LLDB with all the different > > > gdb servers that we can attach to. > > > > > > > It seems that debugserver decrements the pc after stopping on > > breakpoint. > > > To find the stop reason, code in > > > ProcessGDBRemote::SetThreadStopInfo() > > > checks for breakpoint on pc. But gdbserver does not decrement the pc > > > in this case. I had to duplicate the above check for (pc - 1) and > > > then decrement the pc accordingly. I was wondering if there is some > > > good way to distinguish if I am connected to debugserver or > > > gdbserver. Can I make use of some of the new packets added by LLDB > > > or perhaps add some option in the gdb-remote command? > > > > > > I would modify the qHostInfo to return a new key/value pair like: > > > "adjusts_breakpoint_pc:1;" or "adjusts_breakpoint_pc:0;" so we know > > > for certain architectures if we need to manually adjust the PC. Then > > > we use a LazyBool instance variable in GDBRemoteCommunicationClient > > > to detect this setting via the qHostInfo packet. If the > > > "adjusts_breakpoint_pc" key/value isn't specified in the qHostInfo > > > packet, or if the qHostInfo packet isn't supported, we should fall > > > back to a > > setting: > > > > > > (lldb) settings set plugin.process.gdb-remote.adjust-breakpoint-pc > > > true > > > (lldb) settings set plugin.process.gdb-remote.adjust-breakpoint-pc > > > false > > > > > > > > > So with all settings when using GDB server, we try to detect things > > > dynamically (registers and other settings like the adjust breakpoint > > > PC), and if that fails, we fall back to manual settings. > > > > > > Greg _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
