Looks good. Greg
On Oct 9, 2013, at 9:32 AM, Abid, Hafiz <[email protected]> wrote: > 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: [email protected] [mailto:[email protected]] >> On Behalf Of Abid, Hafiz >> Sent: 04 October 2013 17:45 >> To: Greg Clayton >> Cc: [email protected] >> 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:[email protected]] >>> Sent: 05 September 2013 19:26 >>> 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 > <x86_64_gdbserver.xml><xml_register_desc.patch> _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
