On Sep 5, 2013, at 4:04 PM, Kaylor, Andrew <[email protected]> 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: [email protected] [mailto:[email protected]] On
> Behalf Of Greg Clayton
> Sent: Thursday, September 05, 2013 11:26 AM
> 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
> _______________________________________________
> lldb-dev mailing list
> [email protected]
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
