[lldb-dev] About lldbHost

[Zachary Turner via lldb-dev]

Yes, in fact that mirrors how i had planned to tackle this.

The question is, can we put in Utility code that is separated by platform,
which typically has been for Host? This mirrors what llvm does
On Wed, Feb 15, 2017 at 6:29 AM Pavel Labath <labath at google.com> wrote:

> I agree that the next module that needs figuring on is the host one.
> However I am not sure if the decision on what to put in what module
> should be motivated by the FileSpec class, as I think it's current
> interface has a some issues, and our choice on how to resolve them can
> greatly affect what things it depends on.
>
> The main thing that bugs me with FileSpec is that it is used for a two
> distinct purposes:
> - manipulations on abstract path names (e.g. PrependPathComponent)
> - manipulations of actual files present on the host (e.g.
> MemoryMapFileContents)
> For the first one you don't need the files to exist on the host (in
> fact they may not even use the same path syntax as the host). For the
> other one, they *must* exist and *must* use the same path syntax. This
> is currently not very well separated and enforced, and I think it
> should be. I believe this is the reason the FileSystem pseudo-class
> was created.
>
> So, my counter-proposal would be to finish moving the host-specific
> things out of the FileSpec class (basically just replace
> file_spec.Foo(...) with FileSystem::Foo(file_spec, ...). At that point
> FileSpec should only depend on string manipulation functions, and we
> should be able to move it without much hassle. After that, we can take
> another look and decide what to do next.
>
> The thing I really like about this idea is that we will end up with
> two classes that very closely mirror llvm functionality (FileSpec is a
> version of Support/Path.h that does not assume host path syntax,
> FileSystem is similar to Support/FileSystem.h, but it supports some
> more fancy operations like mmap()). Then we could proceed to merge
> this functionality with llvm pretty much independently of any other
> refactoring we will be doing.
>
> What do you think?
>
>
>
> On 15 February 2017 at 01:48, Zachary Turner via lldb-dev
> <lldb-dev at lists.llvm.org> wrote:
> > After https://reviews.llvm.org/D29964, we finally have a starting point
> at
> > which we can begin unravelling the cross-project cyclic dependencies in
> > LLDB.  lldb/Utility now is very similar in spirit to llvm/Support.
> >
> > But llvmSupport goes one step further and includes what lldb would
> normally
> > put under Host.  I think this makes some sense.  Practically all parts
> of a
> > codebase have need of a single OS abstraction layer.  So, I think that a
> lot
> > of the functionality currently in lldbHost is in fact needed by the rest
> of
> > LLDB.
> >
> > So, I wonder if it makes sense to follow the path that LLVM has taken,
> and
> > start moving some of this code from Host down to Utility.  Doing so would
> > allow us to break one of the biggest links in the dependency cycle in the
> > entire codebase, which is that Host depends on everything, and everything
> > depends on Host.
> >
> > Of course, it can't just be a straight move.  Some things in Host
> interact
> > with Target, with CommandInterpreter, and with many other things.  And
> stuff
> > going into Utility can't take a dependency.
> >
> > So there will be some splitting, some moving, some refactoring, etc.
> But to
> > me tackling Host seems like the logical next step, in large part because
> > Host is where FileSpec is, and it's going to be hard to break any
> > dependencies without first addressing FileSpec.
> >
> > The way LLVM handles cross-platform differences in Support is that you
> > include a single header and it does conditional includes into a platform
> > specific subdirectory for the parts that differ.
> >
> > I'm thinking to follow the same pattern here in lldb/Utility, and begin
> > looking for ways to get pieces of Host down into Utility this way, until
> > ultimately I can get FileSpec down there.
> >
> > Thoughts?
> >
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20170215/04cdfe51/attachment.html>