[lldb-dev] LLDB and gdbserver

[Greg Clayton]

On Sep 5, 2013, at 4:04 PM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote:

> Hi Greg,
> 
> Is there any reason not to move the currently hard-coded ARM register information into an XML file once that support is in place?

We could totally do that.

> 
> I'd like to see some mechanism where we'll attempt to choose a register definition file based on the target architecture, but of course having the ability to override the selected file with a settings variable would be desirable.

Yes, we would need to match up the size of the response to the "g" packet along with the target triple to files in a builtin location within the LLDB.framework, and I am not sure where these files would live on linux, but I am sure you can find a location. So maybe we don't need a setting then, just a central place to look for register definition files.

The data could look something like:

<target_definition>
    <triple>arm*-apple-ios</triple>
    <g_packet_size>168</g_packet_size>
    <registers>
        <sets>
            <set id=0>
                <name>General Purpose Registers</name>
                <short_name>gpr</short_name>
            </set>
            <set id=0>
                <name>Floating Point Registers</name>
                <short_name>fpr</short_name>
            </set>
            <set id=0>
                <name>Exception Registers</name>
                <short_name>exc</short_name>
            </set>
        </sets>
        <register_infos>
            <register id=0>
                <name>rax</name>
                <bitsize>64</bitsize>
                <offset>0</offset>
                <encoding>uint</encoding>
                <format>hex</format>
                <set>0</set>
                <compiler_regnum>0</compiler_regnum>
                <dwarf_regnum>0</dwarf_regnum>
                <invalidate-regs>0,15,25,35,39</invalidate-regs>
            </register>
            ....
            <register id=16>
                <name>rip</name>
                <alt_name>pc</alt_name>
                <bitsize>64</bitsize>
                <offset>128</offset>
                <encoding>uint</encoding>
                <format>hex</format>
                <set>0</set>
                <compiler_regnum>16</compiler_regnum>
                <dwarf_regnum>16</dwarf_regnum>
                <generic>pc</generic>
            </register>
        </register_infos>
    </registers>
</target_definition>


Note the "triple" and "g_packet_size" fields that we could use to do matching. The rest is just the same info from the qRegisterInfo packet..


> 
> -Andy
> 
> -----Original Message-----
> From: lldb-dev-bounces at cs.uiuc.edu [mailto:lldb-dev-bounces at cs.uiuc.edu] On Behalf Of Greg Clayton
> Sent: Thursday, September 05, 2013 11:26 AM
> 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