Re: [lldb-dev] About lldbHost

Looked into this a little bit, and it's not a problem AFAICT. LLDB only memory maps in one place, which is from FileSpec::MemoryMapFileContents, and it passes writeable=false. LLVM uses MAP_PRIVATE when writeable==false, so from LLDB's point of view there is no functional change. The writeable c

Re: [lldb-dev] About lldbHost

> On Feb 15, 2017, at 11:22 AM, Zachary Turner wrote: > > Yea, the flag seems like one you would want to use almost always, so I'm not > opposed to having it. I'll see about making the changes in LLVM, even if we > end up not using it in LLDB, they seem useful in LLVM independently. > > BTW,

[lldb-dev] FW: [Dwarf-Discuss] DWARF Version 5 Standard Released

-Original Message- From: Dwarf-Discuss [mailto:dwarf-discuss-boun...@lists.dwarfstd.org] On Behalf Of Michael Eager Sent: Wednesday, February 15, 2017 12:11 PM To: DWARF Workgroup; DWARF Subject: [Dwarf-Discuss] DWARF Version 5 Standard Released The DWARF Debugging Information Format St

Re: [lldb-dev] About lldbHost

Yea, the flag seems like one you would want to use almost always, so I'm not opposed to having it. I'll see about making the changes in LLVM, even if we end up not using it in LLDB, they seem useful in LLVM independently. BTW, one difference in LLVM's mmap code is that in LLDB we always use MAP_P

Re: [lldb-dev] About lldbHost

> On Feb 15, 2017, at 11:07 AM, Zachary Turner wrote: > > If you only ever call MemoryMapContentsIfLocal, then is that first flag even > doing anything? And if you are passing that flag, then can you just mmap it > always even if non-local? If that is the only call people are using, then we

Re: [lldb-dev] About lldbHost

If you only ever call MemoryMapContentsIfLocal, then is that first flag even doing anything? And if you are passing that flag, then can you just mmap it always even if non-local? I searched the code and only in the windows minidump plugin are we unconditionally mmaping, and that could be changed

Re: [lldb-dev] About lldbHost

> On Feb 15, 2017, at 10:58 AM, Zachary Turner wrote: > > > On Wed, Feb 15, 2017 at 10:47 AM Reid Kleckner > wrote: > On Wed, Feb 15, 2017 at 10:35 AM, Greg Clayton via lldb-dev > mailto:lldb-dev@lists.llvm.org>> wrote: > I am fine with switching mmap over to llvm if i

Re: [lldb-dev] About lldbHost

On Wed, Feb 15, 2017 at 10:47 AM Reid Kleckner wrote: > On Wed, Feb 15, 2017 at 10:35 AM, Greg Clayton via lldb-dev < > lldb-dev@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 m

Re: [lldb-dev] About lldbHost

> On Feb 15, 2017, at 10:37 AM, Pavel Labath wrote: > > On 15 February 2017 at 18:20, Greg Clayton > wrote: >> >> On Feb 15, 2017, at 10:14 AM, Zachary Turner wrote: >> >> I think the main improvement that it provides is that you need *something* >> which represent

Re: [lldb-dev] About lldbHost

On Wed, Feb 15, 2017 at 10:35 AM, Greg Clayton via lldb-dev < lldb-dev@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

Re: [lldb-dev] About lldbHost

On 15 February 2017 at 18:20, Greg Clayton wrote: > > On Feb 15, 2017, at 10:14 AM, Zachary Turner wrote: > > I think the main improvement that it provides is that you need *something* > which represents only a path. Because we use FileSpecs to refer to paths on > remote machines, and then what

Re: [lldb-dev] About lldbHost

> On Feb 15, 2017, at 10:30 AM, Zachary Turner wrote: > > Yes. In some cases I want to try deleting LLDB's implementation and seeing > if we can fall back on LLVM. For example, MemoryMapFileContents comes to > mind. LLVM has some code to memory map files as well. I've spent 0 time > looki

Re: [lldb-dev] About lldbHost

Yes. In some cases I want to try deleting LLDB's implementation and seeing if we can fall back on LLVM. For example, MemoryMapFileContents comes to mind. LLVM has some code to memory map files as well. I've spent 0 time looking into how widely FileSpec::MemoryMapFileContents is used, so it's po

Re: [lldb-dev] About lldbHost

> On Feb 15, 2017, at 10:14 AM, Zachary Turner wrote: > > I think the main improvement that it provides is that you need *something* > which represents only a path. Because we use FileSpecs to refer to paths on > remote machines, and then what does it mean to call Exists or Resolve? So, > w

Re: [lldb-dev] About lldbHost

I think the main improvement that it provides is that you need *something* which represents only a path. Because we use FileSpecs to refer to paths on remote machines, and then what does it mean to call Exists or Resolve? So, we could have something like PathSpec and then have FileSpec contain a P

[lldb-dev] [Bug 31972] New: TestStepOverBreakpoint does not work on windows

https://bugs.llvm.org/show_bug.cgi?id=31972 Bug ID: 31972 Summary: TestStepOverBreakpoint does not work on windows Product: lldb Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement

Re: [lldb-dev] About lldbHost

I would prefer things stay object oriented when possible. I don't think it adds anything by making everything a static function. It is ok where it makes sense, but I would vote to add static functions in the FileSpec class over making purely stand alone functions as they indicate that it should

Re: [lldb-dev] About lldbHost

I prefer free functions as well, but I think switching FileSpec to that would be a non-trivial task. If you want to try it out I would encourage it, but I don't think it's a requirement. On 15 February 2017 at 15:41, Zachary Turner wrote: > Having FileSpec in Utility and FileSystem in Host would

Re: [lldb-dev] About lldbHost

Having FileSpec in Utility and FileSystem in Host would work for now. Any opinions on the FileSpec interface? Llvm's path and file system libraries use free functions for everything. in a perfect world I feel that's the best design, and with lldb we could even do slightly better and make all funct

Re: [lldb-dev] About lldbHost

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 ot

Re: [lldb-dev] About lldbHost

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 wrote: > I agree that the next module that needs figu

Re: [lldb-dev] About lldbHost

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 thin