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

2016-09-19 Thread Greg Clayton via lldb-dev
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, 2016

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

2016-09-19 Thread Greg Clayton via lldb-dev
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 = lldb.process.ReadPointerFromMemory(vtableAddr-8, error) > > prin

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

2016-09-19 Thread via lldb-dev
https://llvm.org/bugs/show_bug.cgi?id=29045 Todd Fiala changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

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

2016-09-19 Thread via lldb-dev
https://llvm.org/bugs/show_bug.cgi?id=29046 Todd Fiala changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

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

2016-09-19 Thread via lldb-dev
https://llvm.org/bugs/show_bug.cgi?id=26261 Todd Fiala changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

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

2016-09-19 Thread Lei Kong via lldb-dev
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 v

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

2016-09-19 Thread Greg Clayton via lldb-dev
> 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 with the way > I get vtableAddress? I will clean up my full script and send it to you if the > follo

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

2016-09-19 Thread Greg Clayton via lldb-dev
> 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 with the >> way I get vtableAddress? I

[lldb-dev] LLDB Evolution - Final Form

2016-09-19 Thread Zachary Turner via lldb-dev
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) th

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

2016-09-19 Thread Sean Callanan via lldb-dev
I'll only comment on the stuff that affects me. > Use llvm streams instead of lldb::StreamString > Supports output re-targeting (stderr, stdout, std::string, etc), printf style > formatting, and type-safe streaming operators. > Interoperates nicely with many existing llvm utility classes > Risk:

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

2016-09-19 Thread Zachary Turner via lldb-dev
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, and type-safe streaming

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

2016-09-19 Thread Enrico Granata via lldb-dev
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 be worth throwing out some

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

2016-09-19 Thread Greg Clayton via lldb-dev
> 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 be worth throwing out some ideas for whe

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

2016-09-19 Thread Zachary Turner via lldb-dev
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 out foundational work

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

2016-09-19 Thread Zachary Turner via lldb-dev
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 what about the difficu

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

2016-09-19 Thread Mehdi Amini via lldb-dev
> On Sep 19, 2016, at 2:02 PM, Greg Clayton via lldb-dev > wrote: > > >> 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 th

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

2016-09-19 Thread Zachary Turner via lldb-dev
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 over pretty smoothly f

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

2016-09-19 Thread Greg Clayton via lldb-dev
> 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 complicated needs of a debugger in lit tests.

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

2016-09-19 Thread Zachary Turner via lldb-dev
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 > not seem practical, and i

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

2016-09-19 Thread Greg Clayton via lldb-dev
> 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 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 >>> s

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

2016-09-19 Thread Greg Clayton via lldb-dev
> 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 from a few weeks ago, I think the dust has > > settled on the co

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

2016-09-19 Thread Zachary Turner via lldb-dev
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 19

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

2016-09-19 Thread Enrico Granata via lldb-dev
> 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 > alternative? Are you expecting to check and handle eve

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

2016-09-19 Thread Zachary Turner via lldb-dev
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 vend it from the ref

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

2016-09-19 Thread Mehdi Amini via lldb-dev
> 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 1:18 PM, Zachary Turner via lldb-dev wrote: Following

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

2016-09-19 Thread Jim Ingham via lldb-dev
> On Sep 19, 2016, at 2:11 PM, Zachary Turner via lldb-dev > 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 complicated needs of a debugge

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

2016-09-19 Thread Jim Ingham via lldb-dev
> 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 extensively, I still > remain

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

2016-09-19 Thread Zachary Turner via lldb-dev
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

2016-09-19 Thread Zachary Turner via lldb-dev
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

2016-09-19 Thread Jim Ingham via lldb-dev
> 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 inconvenient) to test > the

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

2016-09-19 Thread Lei Kong via lldb-dev
Sharing the findings on lldb-dev. Greg helped me figure out the issue, I need to check if symbol address is lldb.LLDB_INVALID_ADDRESS. Things work fine now after the added checking. The remaining issue is to figure out whether symbol.addr.file_addr or symbol.addr.load_addr should be used to get

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

2016-09-19 Thread Jim Ingham via lldb-dev
BTW, another way to achieve this worthy goal is to require that all the lldb command-line commands be written using the C++ Version of the SB API's. It should be its own module, and the driver should link to that, not directly to the LLDB.framework at all. That would also force us to provide a