[lldb-dev] LLDB and gdbserver

Fri Oct 11 10:24:05 PDT 2013

XML patch looks good.

The breakpoint adjust patch, I had these comments:

The patch looks good. The only thing I worry about is someone setting this adjust PC value to something like -1, and then forgetting about it. Then they attach to a program with a different architecture and the PC gets adjusted. I am wondering if this setting should be a dictionary that takes target triple regular expresssions as the key and the value is the adjustment amount? This would stop random PC adjustments from happening on different architectures.

On Oct 11, 2013, at 6:52 AM, Abid, Hafiz <Hafiz_Abid at mentor.com> wrote:

> 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
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev