[lldb-dev] LLDB and gdbserver

[Abid, Hafiz]

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:gclayton at apple.com]
> Sent: 05 September 2013 19:26
> To: Abid, Hafiz
> Cc: lldb-dev at cs.uiuc.edu
> Subject: Re: [lldb-dev] LLDB and gdbserver
> 
> 
> On Sep 5, 2013, at 9:16 AM, Abid, Hafiz <Hafiz_Abid at mentor.com> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: adjust_pc.patch
Type: application/octet-stream
Size: 8395 bytes
Desc: adjust_pc.patch
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20131004/ca9cfc62/attachment.obj>