[lldb-dev] LLDB and gdbserver

[Abid, Hafiz]

Ping. There are 2 patches in this series waiting review.

Thanks,
Abid

> -----Original Message-----
> From: lldb-dev-bounces at cs.uiuc.edu [mailto:lldb-dev-bounces at cs.uiuc.edu]
> On Behalf Of Abid, Hafiz
> Sent: 09 October 2013 17:33
> To: lldb-dev at cs.uiuc.edu
> 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: lldb-dev-bounces at cs.uiuc.edu
> > [mailto:lldb-dev-bounces at cs.uiuc.edu]
> > On Behalf Of Abid, Hafiz
> > Sent: 04 October 2013 17:45
> > To: Greg Clayton
> > Cc: lldb-dev at cs.uiuc.edu
> > 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: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