[lldb-dev] About lldbHost

[Zachary Turner via lldb-dev]

On Wed, Feb 15, 2017 at 10:47 AM Reid Kleckner <rnk at google.com> wrote:

> On Wed, Feb 15, 2017 at 10:35 AM, Greg Clayton via lldb-dev <
> lldb-dev at lists.llvm.org> wrote:
>
> I am fine with switching mmap over to llvm if it works. One important
> thing to LLDB is we have a "mmap if not on remote file system" that must
> continue to work. If you mmap something from a network drive and then it
> gets disconnected, you can crash LLDB. So we have a function we used that
> implements mmap if local, read all contents if remote, that must work to
> avoid crashes.
>
>
> LLVM's MemoryBuffer API already serves too many different use cases.
> Initially it was designed to be a utility for efficiently reading source
> file inputs. It has a bunch of functionality around ensuring that the
> buffer is null terminated, and a boolean to avoid using mmap when the user
> might modify the file concurrently. It's too complicated. I wouldn't
> recommend using it without a good reason beyond just reusing a platform
> abstraction. mmap and MapViewOfFile are not that complicated. LLDB is
> probably better off doing its own thing unless it needs to pass mapped file
> contents to other parts of LLVM, like maybe clang's VFS.
>

I just took a look and it seems like almost a drop in replacement.  Only
thing that would need changing is updating shouldUseMmap() to return false
if a file is on a network share.  But this seems like a good change
independently of lldb.

After that all lldb has to do is say MemoryBuffer::getOpenFile() and
everything works.

Is there a good reason *not* to use it?  Evenif internally the
implementation is complex, the external interface is not

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20170215/e428dbdc/attachment.html>