[Lldb-commits] [PATCH] D49740: Move RegisterValue, Scalar, State from Core to Utility
Zachary Turner via lldb-commits
lldb-commits at lists.llvm.org
Fri Aug 3 12:53:36 PDT 2018
Several months ago when this came up, i hypothesized that Utility would
eventually contain a mix of random stuff some of which may not make sense
in the long term. But that in the meantime, it’s useful to have some sort
of layering abstraction for “has no other dependencies”. Eventually when
this reaches critical mass, a natural separation should present itself,
because all the stuff that conceptually belongs together will be in
Utility. So then we can break Utility up into a more logical separation
On Fri, Aug 3, 2018 at 12:37 PM Pavel Labath via Phabricator <
reviews at reviews.llvm.org> wrote:
> 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
> - 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-commits