This is an archive of the discontinued LLVM Phabricator instance.

Move MemoryRegionInfo into the Utility module
AbandonedPublic

Authored by labath on Mar 5 2019, 8:18 AM.

Details

Summary

MemoryRegionInfo describes the region of memory in a process, but this
does not have to be the liblldb's notion of a process (in fact, this
class is already used in lldb-server, which has a different hierarchy of
process-related classes).

So a better place for it would be in the Utility module (next to
RegisterValue, State and similar). We might also consider creating a new
module for classes like this, because we currently have a number of
classes which can be described as "properties of a process" in the
Utility module.

Event Timeline

labath created this revision.Mar 5 2019, 8:18 AM

I like the idea of having a separate module for this.

One idea for a new module name could be AbstractProcess, but I can't think of anything else better at the moment.

labath added a comment.Mar 6 2019, 7:02 AM

One idea for a new module name could be AbstractProcess, but I can't think of anything else better at the moment.

Yeah, naming the new module might be the hardest problem here. :) I'd call the module ProcessInfo, but we already have a class with that name. :P AbstractProcess might be the next best thing.

So I tried to enumerate what files could possibly go into this new module, and I came up with this list (it's a bit shorter than I originally thought):

  • Environment.h
  • MemoryRegionInfo.h
  • ProcessInfo.h
  • RegisterValue.h
  • State.h
  • TraceOptions.h

They seem to be already self-contained (as in no other Utility file uses those), so the move should be fairly easy. Args.h could be added to the list if CompletionRequest if moved elsewhere, but that may not be a good idea, since Args is also used for the built-in interpreter, and not only for process arguments. ProcessLaunchInfo could go there once PseudoTerminal has been factored out of it.

In terms of the dependency graph, I guess this library would need to come between Utility (so it can use things like ArchSpec and FileSpec) and Host (so we can use it to describe Host processes). Right now that seems to be fine, but it may have implications for the future -- I think this excludes the idea of merging Host and Utility into a single module (which I'm personally fine with), as that would mean this whole chain would collapse.

So, what do you think? Is doing this now worth the trouble or do we wait and see? Is there any other class/file that might fit in here?

labath abandoned this revision.Apr 1 2019, 4:45 AM