Re: [lldb-dev] LLDB Evolution - Final Form

> On Sep 19, 2016, at 3:32 PM, Zachary Turner wrote: > > Ok, in that case I agree with you more. We should test the scripting > interface. It's part of the software, it should be treated as such. 100% on > board. But if we find that it is lacking (or even just

Re: [lldb-dev] LLDB Evolution - Final Form

Ok, in that case I agree with you more. We should test the scripting interface. It's part of the software, it should be treated as such. 100% on board. But if we find that it is lacking (or even just inconvenient) to test the full capabilities of the debugger, we shouldn't force it to. All of

Re: [lldb-dev] LLDB Evolution - Final Form

Obviously I defer to you on whether testing via the SB API is better than what GDB does or used to do. But these are not the only two systems in the world. Having used both LLDB and LLVM's test suite extensively, I still remain unconvinced that LLDB's testing situation could not be improved. Do

Re: [lldb-dev] LLDB Evolution - Final Form

> On Sep 19, 2016, at 3:19 PM, Zachary Turner wrote: > > Obviously I defer to you on whether testing via the SB API is better than > what GDB does or used to do. But these are not the only two systems in the > world. Having used both LLDB and LLVM's test suite

Re: [lldb-dev] LLDB Evolution - Final Form

> On Sep 19, 2016, at 2:34 PM, Greg Clayton wrote: > >> >> On Sep 19, 2016, at 2:20 PM, Mehdi Amini wrote: >> >>> >>> On Sep 19, 2016, at 2:02 PM, Greg Clayton via lldb-dev >>> wrote: >>> >>> On Sep 19, 2016, at

Re: [lldb-dev] LLDB Evolution - Final Form

On Mon, Sep 19, 2016 at 2:37 PM Greg Clayton wrote: > > > Just thinking out loud here, but one possibility is to have multiple > pools. One which is ref counted and one which isn't. If you need > something to live forever, vend it from the non-ref-counted pool. > Otherwise

Re: [lldb-dev] LLDB Evolution - Final Form

> On Sep 19, 2016, at 2:31 PM, Zachary Turner via lldb-dev > wrote: > > > > On Mon, Sep 19, 2016 at 2:20 PM Mehdi Amini > wrote: > > > I’m surprise by your aversion to assertions, what is your suggested >

Re: [lldb-dev] LLDB Evolution - Final Form

FWIW, strlen(nullptr) will also crash just as easily as StringRef(nullptr) will crash, so that one isn't a particularly convincing example of poorly used asserts, since the onus on the developer is exactly the same as with strlen. That said, I still know where you're coming from :) On Mon, Sep

Re: [lldb-dev] LLDB Evolution - Final Form

> On Sep 19, 2016, at 2:24 PM, Zachary Turner wrote: > > > > On Mon, Sep 19, 2016 at 2:02 PM Greg Clayton wrote: > > > On Sep 19, 2016, at 1:18 PM, Zachary Turner via lldb-dev > > wrote: > > > > Following up with Kate's post

Re: [lldb-dev] LLDB Evolution - Final Form

On Mon, Sep 19, 2016 at 2:20 PM Mehdi Amini wrote: > > > I’m surprise by your aversion to assertions, what is your suggested > alternative? Are you expecting to check and handle every possible > invariants everywhere and recover (or signal an error) properly? That does >

Re: [lldb-dev] LLDB Evolution - Final Form

> On Sep 19, 2016, at 2:11 PM, Zachary Turner wrote: > > > > On Mon, Sep 19, 2016 at 2:02 PM Greg Clayton wrote: > > > • Separate testing tools > > • One question that remains open is how to represent > > the

Re: [lldb-dev] LLDB Evolution - Final Form

On Mon, Sep 19, 2016 at 2:02 PM Greg Clayton wrote: > > > On Sep 19, 2016, at 1:18 PM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > Following up with Kate's post from a few weeks ago, I think the dust has > settled on the code reformat and it went

Re: [lldb-dev] LLDB Evolution - Final Form

On Mon, Sep 19, 2016 at 2:02 PM Greg Clayton wrote: > > > • Separate testing tools > > • One question that remains open is how to > represent the complicated needs of a debugger in lit tests. Part a) above > covers the trivial cases, but

Re: [lldb-dev] LLDB Evolution - Final Form

On Mon, Sep 19, 2016 at 1:57 PM Enrico Granata wrote: > > I am definitely not innocent in this regard. However, it does happen for a > reason. > > Sometimes, I am writing code in lldb that is the foundation of something I > need to do over on the Swift.org side. > > I'll lay

Re: [lldb-dev] LLDB Evolution - Final Form

A few remarks > On Sep 19, 2016, at 1:18 PM, Zachary Turner via lldb-dev > wrote: > > Following up with Kate's post from a few weeks ago, I think the dust has > settled on the code reformat and it went over pretty smoothly for the most > part. So I thought it might

Re: [lldb-dev] LLDB Evolution - Final Form

On Mon, Sep 19, 2016 at 1:38 PM Sean Callanan wrote: > I'll only comment on the stuff that affects me. > > >1. Use llvm streams instead of lldb::StreamString > 1. Supports output re-targeting (stderr, stdout, std::string, etc), > printf style formatting,

[lldb-dev] LLDB Evolution - Final Form

Following up with Kate's post from a few weeks ago, I think the dust has settled on the code reformat and it went over pretty smoothly for the most part. So I thought it might be worth throwing out some ideas for where we go from here. I have a large list of ideas (more ideas than time, sadly)

Re: [lldb-dev] OverflowError: in method 'SBProcess_ReadPointerFromMemory', argument 2 of type 'lldb::addr_t'

> On Sep 19, 2016, at 1:09 PM, Greg Clayton wrote: > > >> On Sep 19, 2016, at 10:33 AM, Lei Kong wrote: >> >> You are right, it seems the argument is out of range, both vtableAddr and >> vtableAddr-8 are “8.5” byte long. Maybe there is something wrong

Re: [lldb-dev] OverflowError: in method 'SBProcess_ReadPointerFromMemory', argument 2 of type 'lldb::addr_t'

You are right, it seems the argument is out of range, both vtableAddr and vtableAddr-8 are “8.5” byte long. Maybe there is something wrong with the way I get vtableAddress? I will clean up my full script and send it to you if the following does not provide enough information, thanks much. def

[lldb-dev] [Bug 26261] gtest failure in PythonDataObjectsTest.TestPythonBytes on OS X 10.11

https://llvm.org/bugs/show_bug.cgi?id=26261 Todd Fiala changed: What|Removed |Added Status|NEW |RESOLVED

[lldb-dev] [Bug 29046] SymbolFilePDBTests gtests core dumps on macOS

https://llvm.org/bugs/show_bug.cgi?id=29046 Todd Fiala changed: What|Removed |Added Status|NEW |RESOLVED

[lldb-dev] [Bug 29045] ModuleCacheTest gtest fails on macOS

https://llvm.org/bugs/show_bug.cgi?id=29045 Todd Fiala changed: What|Removed |Added Status|NEW |RESOLVED

Re: [lldb-dev] OverflowError: in method 'SBProcess_ReadPointerFromMemory', argument 2 of type 'lldb::addr_t'

If you want to send your fabdbg.py we can try it out and see if we see anything wrong. > On Sep 19, 2016, at 9:12 AM, Greg Clayton wrote: > > Try printing the type of the value you are passing in the line: > >vtableEndAddr =

Re: [lldb-dev] OverflowError: in method 'SBProcess_ReadPointerFromMemory', argument 2 of type 'lldb::addr_t'

Try printing the type of the value you are passing in the line: vtableEndAddr = lldb.process.ReadPointerFromMemory(vtableAddr-8, error) print type(vtableAddr) print type(vtableAddr-8) It seems like it thinks vtableAddr doesn't fit into a lldb::addr_t which is a uint64_t > On Sep 16,