Hello all, Codeplay reporting in.
We want to do the merge and unification between the windows and trunk branches of LLDB. We are doing lots of work with LLDB and it seems the most sensible thing do to given the amount of effort we currently undertake to maintain both branches locally.
Obviously the merge must not break the buildbots currently running on the non-windows target. Additionally, the tests do not run at all under windows, which is an issue we will need to look into solving. It will be difficult given the fact the windows branch itself will not be able to actually debug on windows, however we'd like to do this to the point where the windows branch can be closed.
Our questions to folk on here: what would be accepted in terms of support for this? It could be quite a large patch, and touch many areas, but it is something that needs done to further advance LLDB support for other architectures and platforms. It will also include changes to the driver so a command line frontend is available for windows.
Are there any reservations folk have for this, and if so, can we overcome them?
Many thanks,
Colin
(cc'd with Deepak, who is also involved with this)
Hello all, Codeplay reporting in.
We want to do the merge and unification between the windows and trunk branches of LLDB. We are doing lots of work with LLDB and it seems the most sensible thing do to given the amount of effort we currently undertake to maintain both branches locally.
Obviously the merge must not break the buildbots currently running on the non-windows target. Additionally, the tests do not run at all under windows, which is an issue we will need to look into solving. It will be difficult given the fact the windows branch itself will not be able to actually debug on windows, however we'd like to do this to the point where the windows branch can be closed.
Our questions to folk on here: what would be accepted in terms of support for this? It could be quite a large patch, and touch many areas, but it is something that needs done to further advance LLDB support for other architectures and platforms. It will also include changes to the driver so a command line frontend is available for windows.
We currently have a MinGW patch that is in the process of trying to get submitted, so I would hold off on any commits/patches until this makes it in. The patch is currently causing deadlocks on linux buildbots. Once this is in, we can then merge top of tree with the windows branch prior to submitting patches for the final windows merge that will allow us to remove the windows branch.
Are there any reservations folk have for this, and if so, can we overcome them?
So first we need to get the MinGW patch submitted, then we can proceed.
Greg
I just checked the the MinGW patch was submitted with revision 189107.
So you can now merge top of tree into the windows branch and start submitting patches.
A few things to keep in mind are that any windows (host specific) features need to be abstracted into the lldb_private::Host layer in a system agnostic interface. The files that implement the features should be in source/Host/windows. The only exceptions is in the .cpp files of plugins (like ConnectionFileDescriptor.cpp) where it is ok, in the .cpp file, to add windows specific function calls and logic.
I look forward to seeing the upcoming patches and getting windows support into top of tree.
Greg
Thanks Greg.
We've done lots of changes internally, but these were done before the MinGW changes (it's quite an old revision, in fact) so we'll look at these and figure out collectively what we can do - it seems others may have also got changes to the same end.
For the avoidance of doubt however, we intend a visual studio native build for windows and a frontend driver to suit.
Colin
A large task remains to re-factor LLDB to generalize remote and native local debugging. This refactoring has been suggested by Greg Clayton and here I’m summarizing the rationale and the high-level refactoring for comment. There are a few goals:
· Platform-independent remote debugging.
· Same source code for tasks common to native local and remote debugging (i.e. related to process, threads and registers).
· Native local debugging that does not require packet preparation and parsing. The main goal is to ensure that the details of packet preparation and parsing don’t affect native local debugging. This keeps debug logs simple and allows problems specific to packet handling to be diagnosed independently of generic issues.
· Separation between the communication required to support gdb-server versus LLDB extensions. The main goal is to ensure a strict LLDB protocol when available while maintaining some level of support for the myriad of applications that implement the gdb-server protocol.
So, the refactoring is aimed at replacing debugserver with a new binary that reuses functionality common to native local and remote debugging. Replacing debugserver is preferable since debugserver isn’t platform independent and it is a mix of communication and process/thread/register smarts. In more detail:
- New lldb-host library containing Host::Process and Host::Thread at the top level. This is a platform-independent service layer used for both native local and remote debugging. In general, the service layer implements basic tasks and assumes that the caller has already established a valid context for the operation. For instance, when enumerating the threads for a process, it assumes that a process attach has completed. For this reason, this is not intended to be a low-level debugger API for public consumption.
a. Host::Process implements basic tasks like attach and thread enumeration.
b. Host::Thread implements basic tasks like manipulating the thread state and uses Host::RegisterContext to manipulate the register set.
c. This Host layer will delegate to platform-specific classes analogous to the POSIX ProcessMonitor. As a result, it will only maintain state when required for performance optimization. For instance, the register set could be cached to service queries as long as the current frame has not changed.
d. The functionality of the Host layer is analogous to the ‘C’ interface in DNB.h used by debugserver.
-
New ProcessNative class derived from lldb::private::Process. This new Process plug-in will start off as a sibling for ProcessPOSIX but eventually replace derivatives of lldb_private::Process used for native local and remote debugging with a single ProcessNative class whose implementation is delegated to Host::Process. This stateful class will represent per-process context needed to implement the LLDB API.
-
New ThreadNative class derived from lldb::private::Thread. This new Thread plug-in will start off as a sibling for POSIXThread, but eventually replace derivatives of lldb_private::Thread that are used for native local and remote debugging with a single ThreadNative class whose implementation is delegated to Host::Thread. This stateful class will represent per-thread context needed to implement the LLDB API.
-
Improved GDBRemoteCommunicationServer class to implement the gdb-server protocol. This class, in development for lldb-platform, will be extended to handle as many packets as the current debugserver. For instance, packets related to the register set. This class will use the new lldb-host library to implement remote debugging.
-
New LLDBRemoteCommunicationServer class (derived from GDBRemoteCommunicationServer) to implement the extensions to the gdb-server protocol required by lldb (i.e. for multi-threaded debugging). The goal here is to maintain compatibility with applications that implement the gdb-server protocol with clear separation for extensions such as a proposed sequence number for packets (to avoid race conditions with asynchronous communications). The LLDBRemoteCommunicationServer will be a strict implementation of LLDB extensions to the gdb-server protocol.
-
Reuse the GDBRemoteCommunicationClient class to prepare and parse packets as required to implement the LLDB command set. Again, the LLDBRemoteCommunicationClient will derive from and delegate most of its work to GDBRemoteCommunicationClient.
-
New tools/lldb-server applet to eventually replace debugserver across platforms. This application will use LLDB/GDBRemoteCommunicationServer classes for communication and an API in development for platform discovery (future SBPlatform). Specifically, lldb-server can optionally use a platform API to simplify the remote launch, lldb-platform can be used independent of a debug target, and lldb-server will use the LLDB protocol (gdb-server protocol with extensions) by default.
Since the new classes can be implemented without impacting the current functionality, we propose doing this work in trunk. Note that Greg’s platform branch was recently merged. Cheers,
I think this all sounds great Ashok.