[lldb-dev] About lldbHost

[Pavel Labath via lldb-dev]

Right, I see. In that case, I guess my response would be "let's wait
and see how things look like after FileSpec is moved".

I kinda like how we have the all the host code in a separate module (I
expect we will have a lot more of it than llvm), but I am not against
it if it turns out there is no other way to organize dependencies. I
just don't think we've reached that point yet -- right now I don't see
why we couldn't have FileSpec in Utility and FileSystem in Host.

Or have you thought ahead and found a problem already?


On 15 February 2017 at 15:17, Zachary Turner <zturner at google.com> wrote:
> 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
>> >