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