[Lldb-commits] [PATCH] D49740: Move RegisterValue, Scalar, State from Core to Utility

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

In https://reviews.llvm.org/D49740#1187799, @jingham wrote:

> I worry a little bit about Utility getting kind of incoherent.  Some of it is clearly utility, some is more there because that's where we are putting the code we're trying to reduce dependencies on so we can share then with lldb-server.  RegisterValue doesn't for instance seem like a "Utility" class to me.  But maybe this is something to revisit once you've gotten at least what you need for lldb-server done?


I think being a mixed bag is kind of an inherent property of the lowest layers. LLVM's Support library is also a collection of utilities, which have very little in common, but can be combined in various interesting ways to do cool stuff.

I am not opposed to opening the discussion of splitting and/or putting these three classes into a difference place right now. If you have an idea on how to organize it, I'd like to hear it.

However, I have to say, that RegisterValue actually *does* seem like a good fit for Utility to me -- it's the kind of a thing (representing a "value" of a "register") that every conceivable debugger will need. So it seems good to have it in a place where everybody can use (Utilize :)) it. It's also not host-dependent, as we want to represent registers on remote machines too, so it does not seem like it belongs to Host (although putting it there would have been enough for my present needs).

The question that I am not too clear on is what then becomes of "Core", which I think had a similar design goal in mind. Once I am finished here, it will become kind of empty. I guess my best current definition for it would be that it is the "core" of this single specific debugger called "liblldb", which ties all of the interesting components from other modules together, and which probably don't make sense to reuse in a different debugger (e.g. for Zachary's tracing debugger, he could conceivably find a use for RegisterValue or other stuff in Utility, but it's unlikely he would ever want to use the Debugger class). However, I am not really clear on which of our current classes would fit this description.

Looking over the current contents of the Utility module, I see only a couple of things that I would not choose to put there:

- CompletionRequest - this sounds like it could go next to the command interpreter
- SafeMachO - ObjectFileMachO ?
- SelectHelper - Host (probably somehow merged with the MainLoop class)

However, I'm not too bothered by them being there either, and I doubt this would help with the issues that are troubling you.


https://reviews.llvm.org/D49740