[lldb-dev] www/architecture.html

[Pavel Labath via lldb-dev]

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 at 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 at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev