That sounds fair, we should definitely make sure we're on the same page. I've put up D34872 to better document state of affairs after the recent refactors.
I am a bit reluctant to try to document the "direction we're heading towards" because that is something where I am still developing clarity, and I believe we will have many discussions about that before it finalizes. However, I can try to explain where I am coming from: The way I see it, we have two main products coming out of the lldb_private namespace: liblldb and lldb-server. I'd like to get their dependencies separated (e.g. being able to build lldb-server without linking in the pretty printers, or maybe even without having clang checked out). However, that is still quite far off. Right now I am looking at just three modules: Utility, Host and Core. I would define Utility as a "semi-random collection of simple algorithms and data structures that have nothing or very little to do with debugging". They shouldn't depend on anything else. Host is "algorithms for doing this to the host that are very likely to be full of ifdefs". To achieve this objective they can use the algorithms and data structures from Utility. I deliberately omitted "data structures" from here, as those need not be defined in Host. For example for getting information about the running process the structure that describes a running process can be in Utility, while the getProcessInfo can be in host. I personally wouldn't be too strict here and say that if a data structure is already in Host, and nothing in Utility needs it, then it can stay there, but I thing Zachary feels differently here. I believe Host shouldn't depend on anything except Utility (unless we invent a new module which will be shared between liblldb and lldb-server) Core is the one that puzzles me the most. I am not really sure how to describe it. What is clear to me is that it contains (or used to contain, now we've moved a lot of it out, but still some remain) a lot of low-level stuff that is used by lldb-server (State, ArchSpec), and a lot of high level stuff which are not used (and probably never will be used) in lldb-server (Debugger, ValueObject). So right now, I am trying to move all of the low level things outside of there and hope that what remains will crystalize into some form. I'd be interested to hear your opinion of what Core should be. Other modules seem to have a fairly well defined purpose. I am not planning on changing it or moving large chunks of them, among other reasons because I am not familiar with enough with their inner workings. (***) I think some of their edges could be reversed, but that's not something I plan to do now, nor I have an idea of how exactly they should be. The main thing how the current situation differs from the state I described is the Host module, so that's why I am focusing on it now. I want to kill it's outgoing edges, and I started the one pointing at Core. There were a couple of easy ones, which I've solved by moving things to Utility (because it made sense according to the definitions above). But now a couple of others remain, which are not so obvious, and I am planning to open separate discussions about them (one of them is about ArchSpec, but I don't want to say anything about that until I go back and re-read what was said previously). I am not sure that this provides the clear intention that you were asking for, but I hope it at least explains what I am presently doing. I'd like to hear your thoughts on that. pavel *** Actually there is one more: Process/gdb-remote. I don't like how large chunks of client and server functionality are in the same module (although it is also nice to have them close together). I have some ideas about what to do there, but I am not going to start implementing them any time soon. On 29 June 2017 at 18:36, Jim Ingham via lldb-dev <lldb-dev@lists.llvm.org> wrote: > The recent and not so recent moves from Core to Utility, etc. have left the > information in this file stale. It was last updated in 2013... > > Can one of the people doing this work (Zachary, Pavel...) take a look at this > and bring it up to date, and maybe make more clear the current intentions for > the layout? That would be helpful for folks coming to work on the project, > and also to give us a common understanding of the structure we're working > towards. > > Thanks! > > Jim > > _______________________________________________ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
