[lldb-dev] Host vs. HostInfo
Zachary Turner
zturner at google.com
Mon Aug 25 12:38:32 PDT 2014
I actually did switch over to using a HostInfo::Initialize() as per our
discussion the other day, I just didn't think to use for that for
GetLLDBPath(). It's a good suggestion though, so I'll add it to my list of
things to do. Feel free to remind me if enough time passes and I still
haven't gotten to it.
On Mon, Aug 25, 2014 at 12:31 PM, Greg Clayton <gclayton at apple.com> wrote:
> As a final cleanup to these changes, can we get get rid of the
> preprocessor macro in the HostInfo::GetLLDBPath() and change over to using
> std::once, or switch to using a static HostInfo::Initialize()?
>
> > On Aug 25, 2014, at 11:42 AM, Zachary Turner <zturner at google.com> wrote:
> >
> > I've had some questions (both privately and in responses to other
> messages on-list) about Host and HostInfo. So I'll explain here in hopes
> of answering for everyone.
> >
> > First, the rationale: Host was getting too big and was starting to turn
> into something like "well, I need to call a platform-specific API, I'll
> make it a static method in Host.cpp". As the platform matrix grows, so
> does the complexity of managing this file. Second, there was no attempt in
> Host.cpp to group logically similar methods together in classes. There
> were filesystem methods, process spawning methods, thread manipulation
> methods, methods to query the value of various os magic numbers, etc. As I
> started thinking about what will need to happen to support various things
> on Windows, I imagined this file exploding in complexity. Even with
> HostWindows.cpp, you can see from looking at Host.cpp that it's not always
> possible or easy to separate platform-specific logic into the platform
> specific Host files.
> >
> > So this refactor attempts to address all of these issues.
> >
> > So far I've been focused on (and mostly completed) moving code from Host
> into two different classes: Filesystem and HostInfo.
> >
> > HostInfo - answers queries about the operating system that LLDB is
> running on. Think of this class as being "const". It doesn't modify your
> OS. If you want to know how much memory is available, or the page size, or
> the path to lldb.exe, you ask HostInfo. Instead of #include "Host.h" and
> writing Host::method(), you #include "HostInfo.h" and write
> HostInfo::method(). When adding new methods, put your method in the
> least-derived class possible where it makes sense and will compile on all
> corresponding platforms.
> >
> > The advantage to this approach is that
> > a) No matter what host OS you're on, you always have all the
> functionality of that host OS available to you through static binding (e.g.
> no casting to a derived type)
> > b) Almost zero pre-processor complexity
> >
> > FileSystem - Has methods like MakeDirectory, RemoveDirectory,
> GetPermissions, etc. Where before you would #include "Host.h" and write
> Host::MakeDirectory(), now you #include "FileSystem.h" and write
> FileSystem::MakeDirectory(...).
> >
> > Remaining work to be done:
> > 1) Nuke DynamicLibrary and use LLVM's
> > 2) Make a HostProcess instantiatable, non-static class, which represents
> a process which is running on the Host OS. Move code from Host.cpp over
> there.
> > 3) Make a HostThread instantiatable, non-static class, which represents
> a thread inside of a process on the Host OS. Move code from Host.cpp over
> there.
> > 4) Make a HostProcessLauncher class, of which derived implementations
> would be WindowsProcessLauncher, PosixSpawnProcessLauncher,
> XpcProcessLauncher, etc. Move code from Host.cpp over there.
> > 5) Update Process plugins to use the appropriate HostProcessLauncher
> classes
> > 6) Delete Host.cpp, as there will be no code left in it anymore.
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140825/372719e4/attachment.html>
More information about the lldb-dev
mailing list