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

[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 full capabilities of the debugger, we shouldn't force it to.

I would make an even stronger statement.  As lldb developers, if there's 
something we want to do and it isn't available, we go add it to lldb_private, 
and maybe wire it up to a command so we can use it.  That's the path of least 
resistance.  If it weren't for writing the testsuite using the SB API's, we 
wouldn't tend to write much code using it ourselves.  Writing test cases for 
the Python API in the testsuite is a nice forcing function to get US using the 
SB API's to solve actual problems.  So where reasonable, I think we actually 
SHOULD force ourselves to use it.

There are some things it is annoying to test from the outside, particularly 
small utility functions that you need to test error cases and the like that 
it's just hard to get the actual debugger to generate reliably.  Those are 
great candidates for white box type unit testing.  But the full capabilities of 
the debugger should either be available through the SB API's or they really 
aren't doing anybody any good.  So if the SB API's are not up to revealing the 
full capabilities of the debugger, we need to fix that, not fall back on using 
stuff only lldb developers can have access just so we can get our tests written 
more quickly.

Jim


> 
> All of our tests right now are full-scale integration tests.  Integration 
> tests are certainly helpful, but they aren't the entire world.  And they 
> shouldn't even be a first line of defense, but rather a 3rd or 4th line of 
> defense due to how general they are.  Like the example I gave earlier about 
> TestSigned and TestUnsigned on Windows, where one was failing and one was 
> passing, and the reason had nothing to do with signedness.  
> 
> On Mon, Sep 19, 2016 at 3:24 PM Jim Ingham  wrote:
> 
> > 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 unconvinced that LLDB's testing situation could not be improved.  Do 
> > we improve it by doing what GDB did?  Obviously not.  Can we improve it 
> > further by doing something completely different than what GDB did *and* 
> > what LLDB currently does?  I remain convinced that we can.
> 
> I think you misread my message.  I said:
> 
> Having a Python interface so that developers can program the debugger is very 
> powerful.
> 
> As evidence, see all the work the gdb folks did to add one (you have to know 
> a little bit about how gdb works to see how hard this would be, but you can 
> imagine a debugger written in C primarily to dump text to a terminal, think 
> of how you would wrap that in Python and you'll get a sense.)
> 
> Now forget about gdb, that was only an example of how much some folks thought 
> a scripting interface was worth.
> 
> Instead, focus on this good thing, the scripting interface.  We should test 
> this thing that we think is valuable.
> 
> What's a good way to make sure we test that?
> 
> USE IT FOR TESTING.
> 
> Jim
> 
> 
> >
> >
> > On Mon, Sep 19, 2016 at 3:07 PM Jim Ingham  wrote:
> >
> > > 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 debugger in lit tests.  Part a) 
> > > > above covers the trivial cases, but what about the difficult cases?  In 
> > > > https://reviews.llvm.org/D24591 a number of ideas were discussed.  We 
> > > > started getting to this idea towards the end, about a separate tool 
> > > > which has an interface independent of the command line interface and 
> > > > which can be used to test.  lldb-mi was mentioned.  While I have 
> > > > serious concerns about lldb-mi due to its poorly written and tested 
> > > > codebase, I do agree in principle with the methodology.  In fact, this 
> > > > is the entire philosophy behind lit as used with LLVM, clang, lld, etc.
> > >
> > > We have a public API... Why are we going to go and spend _any_ time on 
> > > doing anything else? I just don't get it. What a waste of time. We have a 
> > > public API. Lets use it. Not simple enough for people? Tough. Testing a 
> > > debugger should be done using the public API except when we are actually 
> > > trying to test 

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

[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 our tests right now are full-scale integration tests.  Integration
tests are certainly helpful, but they aren't the entire world.  And they
shouldn't even be a first line of defense, but rather a 3rd or 4th line of
defense due to how general they are.  Like the example I gave earlier about
TestSigned and TestUnsigned on Windows, where one was failing and one was
passing, and the reason had nothing to do with signedness.

On Mon, Sep 19, 2016 at 3:24 PM Jim Ingham  wrote:

>
> > 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 unconvinced that LLDB's testing situation could not be
> improved.  Do we improve it by doing what GDB did?  Obviously not.  Can we
> improve it further by doing something completely different than what GDB
> did *and* what LLDB currently does?  I remain convinced that we can.
>
> I think you misread my message.  I said:
>
> Having a Python interface so that developers can program the debugger is
> very powerful.
>
> As evidence, see all the work the gdb folks did to add one (you have to
> know a little bit about how gdb works to see how hard this would be, but
> you can imagine a debugger written in C primarily to dump text to a
> terminal, think of how you would wrap that in Python and you'll get a
> sense.)
>
> Now forget about gdb, that was only an example of how much some folks
> thought a scripting interface was worth.
>
> Instead, focus on this good thing, the scripting interface.  We should
> test this thing that we think is valuable.
>
> What's a good way to make sure we test that?
>
> USE IT FOR TESTING.
>
> Jim
>
>
> >
> >
> > On Mon, Sep 19, 2016 at 3:07 PM Jim Ingham  wrote:
> >
> > > On Sep 19, 2016, at 2:11 PM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> 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.  Part a) above
> covers the trivial cases, but what about the difficult cases?  In
> https://reviews.llvm.org/D24591 a number of ideas were discussed.  We
> started getting to this idea towards the end, about a separate tool which
> has an interface independent of the command line interface and which can be
> used to test.  lldb-mi was mentioned.  While I have serious concerns about
> lldb-mi due to its poorly written and tested codebase, I do agree in
> principle with the methodology.  In fact, this is the entire philosophy
> behind lit as used with LLVM, clang, lld, etc.
> > >
> > > We have a public API... Why are we going to go and spend _any_ time on
> doing anything else? I just don't get it. What a waste of time. We have a
> public API. Lets use it. Not simple enough for people? Tough. Testing a
> debugger should be done using the public API except when we are actually
> trying to test the LLDB command line in pexpect like tests. Those and only
> those are fine to covert over to using LIT and use text scraping. But 95%
> of our testing should be done using the API that our IDEs use. Using MI?
> Please no.
> > >
> > > FWIW, I agree with you about mi.
> > >
> > > That said, the public api is problematic.  Here you've got an API
> which, once you do something to, is set in stone forever.  And yet in order
> to test something, you have to add it to the API.  So now, in order to test
> something, you have to make a permanent change to a public API that can
> never be undone.
> > >
> > > It's also a public facing API, when a lot of the stuff  we need to be
> able to look at and inspect is not really suitable for public consumption.
> > >
> > > If something is a public API that can never be changed once it's
> added, then there should be an extremely strict review process in order to
> add something to it.  It should be VERY HARD to modify (it's currently not,
> which is a debate for another day, but anyway...).  And yet that's
> fundamentally incompatible with having tests be easy to write.  When it's
> hard to add the thing you need to add in order to write the test, then it's
> hard to write the test.
> > >
> > > Furthermore, with a system such as the one I proposed, you could even
> run tests with LLDB_DISABLE_PYTHON.  IDK about you, but that would be
> *amazing* from my point of view.  Even though I spent months making 

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

[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
we improve it by doing what GDB did?  Obviously not.  Can we improve it
further by doing something completely different than what GDB did *and*
what LLDB currently does?  I remain convinced that we can.


On Mon, Sep 19, 2016 at 3:07 PM Jim Ingham  wrote:

>
> > On Sep 19, 2016, at 2:11 PM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> 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.  Part a) above
> covers the trivial cases, but what about the difficult cases?  In
> https://reviews.llvm.org/D24591 a number of ideas were discussed.  We
> started getting to this idea towards the end, about a separate tool which
> has an interface independent of the command line interface and which can be
> used to test.  lldb-mi was mentioned.  While I have serious concerns about
> lldb-mi due to its poorly written and tested codebase, I do agree in
> principle with the methodology.  In fact, this is the entire philosophy
> behind lit as used with LLVM, clang, lld, etc.
> >
> > We have a public API... Why are we going to go and spend _any_ time on
> doing anything else? I just don't get it. What a waste of time. We have a
> public API. Lets use it. Not simple enough for people? Tough. Testing a
> debugger should be done using the public API except when we are actually
> trying to test the LLDB command line in pexpect like tests. Those and only
> those are fine to covert over to using LIT and use text scraping. But 95%
> of our testing should be done using the API that our IDEs use. Using MI?
> Please no.
> >
> > FWIW, I agree with you about mi.
> >
> > That said, the public api is problematic.  Here you've got an API which,
> once you do something to, is set in stone forever.  And yet in order to
> test something, you have to add it to the API.  So now, in order to test
> something, you have to make a permanent change to a public API that can
> never be undone.
> >
> > It's also a public facing API, when a lot of the stuff  we need to be
> able to look at and inspect is not really suitable for public consumption.
> >
> > If something is a public API that can never be changed once it's added,
> then there should be an extremely strict review process in order to add
> something to it.  It should be VERY HARD to modify (it's currently not,
> which is a debate for another day, but anyway...).  And yet that's
> fundamentally incompatible with having tests be easy to write.  When it's
> hard to add the thing you need to add in order to write the test, then it's
> hard to write the test.
> >
> > Furthermore, with a system such as the one I proposed, you could even
> run tests with LLDB_DISABLE_PYTHON.  IDK about you, but that would be
> *amazing* from my point of view.  Even though I spent months making Python
> 3 work, I would be happy to burn it all with fire and go back to just
> Python 2 if we had a viable testing strategy.
>
> It would not be amazing.  One of the primary benefits of lldb IS the
> Python API.  If you don't think that's wonderful in a debugger, go look at
> what effort it took to make that happen in gdb once lldb started providing
> it and you'll see that it was really highly motivated.  So switching our
> testing away from one of our very strong points would be a very bad choice
> IMHO.
>
> On the "should I add it to the SB API to test it or not question."  Most
> of the time, when I find I need to add an API in order write a test for
> something, the thing I'm trying to get my hands on is something that other
> people might be interested in as well.  If we go to the mode of adding
> affordances only for ourselves when writing for testing, we remove one of
> the times you should be asking yourself "should I add this to the SB API so
> other people can use it."  I'm fine with having an lldb-testing module with
> API's based on the same methodology as the SB API's.  If you think
> something you are adding is too esoteric to be part of the SB API put it
> there.  But by default put it into the SB API's.
>
> Jim
>
>
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[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 unconvinced that LLDB's testing situation could not be improved.  Do 
> we improve it by doing what GDB did?  Obviously not.  Can we improve it 
> further by doing something completely different than what GDB did *and* what 
> LLDB currently does?  I remain convinced that we can.

I think you misread my message.  I said:

Having a Python interface so that developers can program the debugger is very 
powerful.

As evidence, see all the work the gdb folks did to add one (you have to know a 
little bit about how gdb works to see how hard this would be, but you can 
imagine a debugger written in C primarily to dump text to a terminal, think of 
how you would wrap that in Python and you'll get a sense.)

Now forget about gdb, that was only an example of how much some folks thought a 
scripting interface was worth.

Instead, focus on this good thing, the scripting interface.  We should test 
this thing that we think is valuable.

What's a good way to make sure we test that?

USE IT FOR TESTING.

Jim


> 
> 
> On Mon, Sep 19, 2016 at 3:07 PM Jim Ingham  wrote:
> 
> > 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 debugger in lit tests.  Part a) 
> > > above covers the trivial cases, but what about the difficult cases?  In 
> > > https://reviews.llvm.org/D24591 a number of ideas were discussed.  We 
> > > started getting to this idea towards the end, about a separate tool which 
> > > has an interface independent of the command line interface and which can 
> > > be used to test.  lldb-mi was mentioned.  While I have serious concerns 
> > > about lldb-mi due to its poorly written and tested codebase, I do agree 
> > > in principle with the methodology.  In fact, this is the entire 
> > > philosophy behind lit as used with LLVM, clang, lld, etc.
> >
> > We have a public API... Why are we going to go and spend _any_ time on 
> > doing anything else? I just don't get it. What a waste of time. We have a 
> > public API. Lets use it. Not simple enough for people? Tough. Testing a 
> > debugger should be done using the public API except when we are actually 
> > trying to test the LLDB command line in pexpect like tests. Those and only 
> > those are fine to covert over to using LIT and use text scraping. But 95% 
> > of our testing should be done using the API that our IDEs use. Using MI? 
> > Please no.
> >
> > FWIW, I agree with you about mi.
> >
> > That said, the public api is problematic.  Here you've got an API which, 
> > once you do something to, is set in stone forever.  And yet in order to 
> > test something, you have to add it to the API.  So now, in order to test 
> > something, you have to make a permanent change to a public API that can 
> > never be undone.
> >
> > It's also a public facing API, when a lot of the stuff  we need to be able 
> > to look at and inspect is not really suitable for public consumption.
> >
> > If something is a public API that can never be changed once it's added, 
> > then there should be an extremely strict review process in order to add 
> > something to it.  It should be VERY HARD to modify (it's currently not, 
> > which is a debate for another day, but anyway...).  And yet that's 
> > fundamentally incompatible with having tests be easy to write.  When it's 
> > hard to add the thing you need to add in order to write the test, then it's 
> > hard to write the test.
> >
> > Furthermore, with a system such as the one I proposed, you could even run 
> > tests with LLDB_DISABLE_PYTHON.  IDK about you, but that would be *amazing* 
> > from my point of view.  Even though I spent months making Python 3 work, I 
> > would be happy to burn it all with fire and go back to just Python 2 if we 
> > had a viable testing strategy.
> 
> It would not be amazing.  One of the primary benefits of lldb IS the Python 
> API.  If you don't think that's wonderful in a debugger, go look at what 
> effort it took to make that happen in gdb once lldb started providing it and 
> you'll see that it was really highly motivated.  So switching our testing 
> away from one of our very strong points would be a very bad choice IMHO.
> 
> On the "should I add it to the SB API to test it or not question."  Most of 
> the time, when I find I need to add an API in order write a test for 
> something, the thing I'm trying to get my hands on is something that other 
> people might 

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

[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 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) 
 that I've been collecting over the past few weeks, so I figured I would 
 throw them out in the open for discussion.
 
 I’ve grouped the areas for improvement into 3 high level categories.
 
• De-inventing the wheel - We should use more code from LLVM, and 
 delete code in LLDB where LLVM provides a solution.  In cases where there 
 is an LLVM thing that is *similar* to what we need, we should extend the 
 LLVM thing to support what we need, and then use it.  Following are some 
 areas I've identified.  This list is by no means complete.  For each one, 
 I've given a personal assessment of how likely it is to cause some 
 (temporary) hiccups, how much it would help us in the long run, and how 
 difficult it would be to do.  Without further ado:
• Use llvm::Regex instead of lldb::Regex
• llvm::Regex doesn’t support enhanced mode.  Could we 
 add support for this to llvm::Regex?
• Risk: 6
• Impact: 3
• Difficulty / Effort: 3  (5 if we have to add enhanced 
 mode support)
>>> 
>>> As long as it supports all of the features, then this is fine. Otherwise we 
>>> will need to modify the regular expressions to work with the LLVM version 
>>> or back port any advances regex features we need into the LLVM regex 
>>> parser. 
>>> 
• 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: 4
• Impact: 5
• Difficulty / Effort: 7
>>> 
>>> I have worked extensively with both C++ streams and with printf. I don't 
>>> find the type safe streaming operators to be readable and a great way to 
>>> place things into streams. Part of my objection to this will be quelled if 
>>> the LLVM streams are not stateful like C++ streams are (add an extra 
>>> "std::hex" into the stream and suddenly other things down stream start 
>>> coming out in hex). As long as printf functionality is in the LLVM streams 
>>> I am ok with it.
>>> 
• Use llvm::Error instead of lldb::Error
• llvm::Error is an error class that *requires* you to 
 check whether it succeeded or it will assert.  In a way, it's similar to a 
 C++ exception, except that it doesn't come with the performance hit 
 associated with exceptions.  It's extensible, and can be easily extended 
 to support the various ways LLDB needs to construct errors and error 
 messages.
• Would need to first rename lldb::Error to LLDBError 
 so that te conversion from LLDBError to llvm::Error could be done 
 incrementally.
• Risk: 7
• Impact: 7
• Difficulty / Effort: 8
>>> 
>>> We must be very careful here. Nothing can crash LLDB and adding something 
>>> that will be known to crash in some cases can only be changed if there is a 
>>> test that can guarantee that it won't crash. assert() calls in a shared 
>>> library like LLDB are not OK and shouldn't fire. Even if they do, when 
>>> asserts are off, then it shouldn't crash LLDB. We have made efforts to only 
>>> use asserts in LLDB for things that really can't happen, but for things 
>>> like constructing a StringRef with NULL is one example of why I don't want 
>>> to use certain classes in LLVM. If we can remove the crash threat, then 
>>> lets use them. But many people firmly believe that asserts belong in llvm 
>>> and clang code and I don't agree.
>> 
>> 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 it seems to me that it'd lead to just involving UB (or 
>> breaking design invariant) without actually noticing it.
> 
> We have to as a debugger. We get input from a variety of different 

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

[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 counted pool.
>
> Again, since we already are using LLVM under the hood here, I would hope
> to avoid changes if possible.
>
> Right, but we aren't specifically using the llvm::StringPool class which
ref counts.  idk, maybe there wouldnt' be much savings, but I remember you
saying a long time ago that ConstStrings are a huge source of memory usage
in LLDB.  So it seems like if we could ref-count when possible, it would be
a major savings.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[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 every possible invariants 
> everywhere and recover (or signal an error) properly? That does not seem 
> practical, and it seems to me that it'd lead to just involving UB (or 
> breaking design invariant) without actually noticing it.
> 
> > Also many asserts are in header files so even if you build llvm and clang 
> > with asserts off, but then build our project that uses LLVM with asserts 
> > on, you get LLVM and clang asserts when you don't want them.
> 
> It is not really supported to use the LLVM C++ headers without assertions and 
> link to a LLVM build with assertions (and vice-versa).
>  
> It seems to me that you are mixing two things: asserting on user inputs vs 
> asserting on internal invariants of the system. LLVM is very intensive about 
> asserting on the second category and this seems fine to me.
> Asserting on external inputs is not great (in LLVM as much as in LLDB).
> 
> The asserting error class above falls into the second category and is a great 
> tool to enforce programmer error
> 
> 
> I can kind of see both sides on this one.  Yes, if you can catch instances of 
> UB before it happens that's helpful.  At the same time, when you've got a 
> product (such as, say, Xcode), you also want to try as hard as possible not 
> to bring the whole product down.  In lldb we have lldbassert, which asserts 
> for real in debug, but in release it logs an error to a file.  This is nice 
> because if someone submits a crash report, we can see the assertion failure 
> in the log file.
> 
> Now, obviously the *real* solution is to make LLDB out-of-process so it 
> doesn't bring down Xcode when it crashes.  But (and I have no knowledge of 
> the Xcode / LLDB integration) I can easily see this being a monumental amount 
> of effort.
> 

Even then, IMO you are not out of the business of not crashing on people
Sure, now you didn't crash all of Xcode, but you still lost somebody's debug 
session with potentially valuable state in it...

It sounds like llvm::Expected + lldbassert() is a good combination; it makes 
sure we don't just drop error conditions on the ground, but it also makes sure 
that we don't just give up the ghost and crash..

> Personally, asserting in LLDB doesn't affect me and I'm fine with lldb::Error 
> asserting..  But I can kind of see the argument for not wanting it to assert. 
>  
> 
> On the other hand, if we had better test coverage, then all

I wonder if catching them all can't somehow be reduced to the halting problem 
:) Most would already be great!

> of these assertions would be caught during test anyway.  Which brings us back 
> to item #2 on my list...
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


Thanks,
- Enrico
 egranata@.com ☎️ 27683

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[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, 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 <
> lldb-dev@lists.llvm.org> 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 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) that I've been collecting over the past few weeks, so I figured I
> would throw them out in the open for discussion.
> >>>
> >>> I’ve grouped the areas for improvement into 3 high level categories.
> >>>
> >>> • De-inventing the wheel - We should use more code from LLVM, and
> delete code in LLDB where LLVM provides a solution.  In cases where there
> is an LLVM thing that is *similar* to what we need, we should extend the
> LLVM thing to support what we need, and then use it.  Following are some
> areas I've identified.  This list is by no means complete.  For each one,
> I've given a personal assessment of how likely it is to cause some
> (temporary) hiccups, how much it would help us in the long run, and how
> difficult it would be to do.  Without further ado:
> >>> • Use llvm::Regex instead of lldb::Regex
> >>> • llvm::Regex doesn’t support enhanced mode.
> Could we add support for this to llvm::Regex?
> >>> • Risk: 6
> >>> • Impact: 3
> >>> • Difficulty / Effort: 3  (5 if we have to add
> enhanced mode support)
> >>
> >> As long as it supports all of the features, then this is fine.
> Otherwise we will need to modify the regular expressions to work with the
> LLVM version or back port any advances regex features we need into the LLVM
> regex parser.
> >>
> >>> • 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: 4
> >>> • Impact: 5
> >>> • Difficulty / Effort: 7
> >>
> >> I have worked extensively with both C++ streams and with printf. I
> don't find the type safe streaming operators to be readable and a great way
> to place things into streams. Part of my objection to this will be quelled
> if the LLVM streams are not stateful like C++ streams are (add an extra
> "std::hex" into the stream and suddenly other things down stream start
> coming out in hex). As long as printf functionality is in the LLVM streams
> I am ok with it.
> >>
> >>> • Use llvm::Error instead of lldb::Error
> >>> • llvm::Error is an error class that *requires*
> you to check whether it succeeded or it will assert.  In a way, it's
> similar to a C++ exception, except that it doesn't come with the
> performance hit associated with exceptions.  It's extensible, and can be
> easily extended to support the various ways LLDB needs to construct errors
> and error messages.
> >>> • Would need to first rename lldb::Error to
> LLDBError so that te conversion from LLDBError to llvm::Error could be done
> incrementally.
> >>> • Risk: 7
> >>> • Impact: 7
> >>> • Difficulty / Effort: 8
> >>
> >> We must be very careful here. Nothing can crash LLDB and adding
> something that will be known to crash in some cases can only be changed if
> there is a test that can guarantee that it won't crash. assert() calls in a
> shared library like LLDB are not OK and shouldn't fire. Even if they do,
> when asserts are off, then it shouldn't crash LLDB. We have made efforts to
> only use asserts in LLDB for things that really can't happen, but for
> things like constructing a StringRef with NULL is one example of why I
> don't want to use certain classes in LLVM. If we can remove the crash
> threat, then lets use them. But many people firmly believe that asserts
> belong in llvm and clang code and I don't agree.
> >
> > 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 it seems to me that it'd 

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

[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 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) 
> > that I've been collecting over the past few weeks, so I figured I would 
> > throw them out in the open for discussion.
> >
> > I’ve grouped the areas for improvement into 3 high level categories.
> >
> >   • De-inventing the wheel - We should use more code from LLVM, and 
> > delete code in LLDB where LLVM provides a solution.  In cases where there 
> > is an LLVM thing that is *similar* to what we need, we should extend the 
> > LLVM thing to support what we need, and then use it.  Following are some 
> > areas I've identified.  This list is by no means complete.  For each one, 
> > I've given a personal assessment of how likely it is to cause some 
> > (temporary) hiccups, how much it would help us in the long run, and how 
> > difficult it would be to do.  Without further ado:
> >   • Use llvm::Regex instead of lldb::Regex
> >   • llvm::Regex doesn’t support enhanced mode.  Could 
> > we add support for this to llvm::Regex?
> >   • Risk: 6
> >   • Impact: 3
> >   • Difficulty / Effort: 3  (5 if we have to add 
> > enhanced mode support)
> 
> As long as it supports all of the features, then this is fine. Otherwise we 
> will need to modify the regular expressions to work with the LLVM version or 
> back port any advances regex features we need into the LLVM regex parser.
> 
> >   • 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: 4
> >   • Impact: 5
> >   • Difficulty / Effort: 7
> 
> I have worked extensively with both C++ streams and with printf. I don't find 
> the type safe streaming operators to be readable and a great way to place 
> things into streams. Part of my objection to this will be quelled if the LLVM 
> streams are not stateful like C++ streams are (add an extra "std::hex" into 
> the stream and suddenly other things down stream start coming out in hex). As 
> long as printf functionality is in the LLVM streams I am ok with it.
> I agree with you on the streams for the most part.  llvm streams do not use 
> stateful manipulators, although they do have stateless manipulators.  For 
> example, you can write:
> 
> stream << llvm::format_hex(n);
> 
> and that would print n as hex, but it wouldn't affect the printing of 
> subsequent items.  You also still get printf style formatting by using the 
> llvm::format stateless manipulator.  Like this:
> 
> stream << llvm::format("%0.4f", myfloat)
>  
> 
> >   • Use llvm::Error instead of lldb::Error
> >   • llvm::Error is an error class that *requires* you 
> > to check whether it succeeded or it will assert.  In a way, it's similar to 
> > a C++ exception, except that it doesn't come with the performance hit 
> > associated with exceptions.  It's extensible, and can be easily extended to 
> > support the various ways LLDB needs to construct errors and error messages.
> >   • Would need to first rename lldb::Error to LLDBError 
> > so that te conversion from LLDBError to llvm::Error could be done 
> > incrementally.
> >   • Risk: 7
> >   • Impact: 7
> >   • Difficulty / Effort: 8
> 
> We must be very careful here. Nothing can crash LLDB and adding something 
> that will be known to crash in some cases can only be changed if there is a 
> test that can guarantee that it won't crash. assert() calls in a shared 
> library like LLDB are not OK and shouldn't fire. Even if they do, when 
> asserts are off, then it shouldn't crash LLDB. We have made efforts to only 
> use asserts in LLDB for things that really can't happen, but for things like 
> constructing a StringRef with NULL is one example of why I don't want to use 
> certain classes in LLVM. If we can remove the crash threat, then lets use 
> them. But many people firmly believe that asserts belong in llvm and clang 
> code and I don't agree. Also many asserts are in header files so even if you 
> build llvm and clang with asserts off, but then build our project that uses 
> LLVM 

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

[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 it seems to me that it'd lead to just involving UB
> (or breaking design invariant) without actually noticing it.
>
> > Also many asserts are in header files so even if you build llvm and
> clang with asserts off, but then build our project that uses LLVM with
> asserts on, you get LLVM and clang asserts when you don't want them.
>
> It is not really supported to use the LLVM C++ headers without assertions
> and link to a LLVM build with assertions (and vice-versa).
>


> It seems to me that you are mixing two things: asserting on user inputs vs
> asserting on internal invariants of the system. LLVM is very intensive
> about asserting on the second category and this seems fine to me.
> Asserting on external inputs is not great (in LLVM as much as in LLDB).
>
> The asserting error class above falls into the second category and is a
> great tool to enforce programmer error
>
>
I can kind of see both sides on this one.  Yes, if you can catch instances
of UB before it happens that's helpful.  At the same time, when you've got
a product (such as, say, Xcode), you also want to try as hard as possible
not to bring the whole product down.  In lldb we have lldbassert, which
asserts for real in debug, but in release it logs an error to a file.  This
is nice because if someone submits a crash report, we can see the assertion
failure in the log file.

Now, obviously the *real* solution is to make LLDB out-of-process so it
doesn't bring down Xcode when it crashes.  But (and I have no knowledge of
the Xcode / LLDB integration) I can easily see this being a monumental
amount of effort.

Personally, asserting in LLDB doesn't affect me and I'm fine with
lldb::Error asserting..  But I can kind of see the argument for not wanting
it to assert.

On the other hand, if we had better test coverage, then all of these
assertions would be caught during test anyway.  Which brings us back to
item #2 on my list...
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[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.  Part a) above covers the 
> > trivial cases, but what about the difficult cases?  In 
> > https://reviews.llvm.org/D24591 a number of ideas were discussed.  We 
> > started getting to this idea towards the end, about a separate tool which 
> > has an interface independent of the command line interface and which can be 
> > used to test.  lldb-mi was mentioned.  While I have serious concerns about 
> > lldb-mi due to its poorly written and tested codebase, I do agree in 
> > principle with the methodology.  In fact, this is the entire philosophy 
> > behind lit as used with LLVM, clang, lld, etc.
> 
> We have a public API... Why are we going to go and spend _any_ time on doing 
> anything else? I just don't get it. What a waste of time. We have a public 
> API. Lets use it. Not simple enough for people? Tough. Testing a debugger 
> should be done using the public API except when we are actually trying to 
> test the LLDB command line in pexpect like tests. Those and only those are 
> fine to covert over to using LIT and use text scraping. But 95% of our 
> testing should be done using the API that our IDEs use. Using MI? Please no.
> 
> FWIW, I agree with you about mi.
> 
> That said, the public api is problematic.  Here you've got an API which, once 
> you do something to, is set in stone forever.  And yet in order to test 
> something, you have to add it to the API.  So now, in order to test 
> something, you have to make a permanent change to a public API that can never 
> be undone.

So let me clarify: I don't want people adding to the public API for the sole 
reason of testing.. That falls into the "test another way" category. So I 
should have said "add it to the public API if it would be a valid addition to 
the public API.
> 
> It's also a public facing API, when a lot of the stuff  we need to be able to 
> look at and inspect is not really suitable for public consumption.

Again, this falls into the "test another way" category as is perfect for gtest 
or lit.
> 
> If something is a public API that can never be changed once it's added, then 
> there should be an extremely strict review process in order to add something 
> to it.  It should be VERY HARD to modify (it's currently not, which is a 
> debate for another day, but anyway...).  And yet that's fundamentally 
> incompatible with having tests be easy to write.  When it's hard to add the 
> thing you need to add in order to write the test, then it's hard to write the 
> test.

Yes yes yes. Sorry about the confusion. My first sentence should clear this 
up...

> 
> Furthermore, with a system such as the one I proposed, you could even run 
> tests with LLDB_DISABLE_PYTHON.  IDK about you, but that would be *amazing* 
> from my point of view.  Even though I spent months making Python 3 work, I 
> would be happy to burn it all with fire and go back to just Python 2 if we 
> had a viable testing strategy.

I am not opposed to that. That being say we could start having most API tests 
actually use the C++ public API and have the tests written in C++. We would 
need a .a file with some canned functionality in it, but anything that is 
testing the public API could just be C++. 

So I definitely don't want people adding to the public API just for testing. 
The rules should be:
- Does my feature belong in the public API?
  - Yes, great, add it and test it there
  - No, test it with gtest or lit

Greg


___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[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 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)
> that I've been collecting over the past few weeks, so I figured I would
> throw them out in the open for discussion.
> >
> > I’ve grouped the areas for improvement into 3 high level categories.
> >
> >   • De-inventing the wheel - We should use more code from LLVM, and
> delete code in LLDB where LLVM provides a solution.  In cases where there
> is an LLVM thing that is *similar* to what we need, we should extend the
> LLVM thing to support what we need, and then use it.  Following are some
> areas I've identified.  This list is by no means complete.  For each one,
> I've given a personal assessment of how likely it is to cause some
> (temporary) hiccups, how much it would help us in the long run, and how
> difficult it would be to do.  Without further ado:
> >   • Use llvm::Regex instead of lldb::Regex
> >   • llvm::Regex doesn’t support enhanced mode.
> Could we add support for this to llvm::Regex?
> >   • Risk: 6
> >   • Impact: 3
> >   • Difficulty / Effort: 3  (5 if we have to add
> enhanced mode support)
>
> As long as it supports all of the features, then this is fine. Otherwise
> we will need to modify the regular expressions to work with the LLVM
> version or back port any advances regex features we need into the LLVM
> regex parser.
>
> >   • 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: 4
> >   • Impact: 5
> >   • Difficulty / Effort: 7
>
> I have worked extensively with both C++ streams and with printf. I don't
> find the type safe streaming operators to be readable and a great way to
> place things into streams. Part of my objection to this will be quelled if
> the LLVM streams are not stateful like C++ streams are (add an extra
> "std::hex" into the stream and suddenly other things down stream start
> coming out in hex). As long as printf functionality is in the LLVM streams
> I am ok with it.
>
I agree with you on the streams for the most part.  llvm streams do not use
stateful manipulators, although they do have stateless manipulators.  For
example, you can write:

stream << llvm::format_hex(n);

and that would print n as hex, but it wouldn't affect the printing of
subsequent items.  You also still get printf style formatting by using the
llvm::format stateless manipulator.  Like this:

stream << llvm::format("%0.4f", myfloat)


>
> >   • Use llvm::Error instead of lldb::Error
> >   • llvm::Error is an error class that *requires*
> you to check whether it succeeded or it will assert.  In a way, it's
> similar to a C++ exception, except that it doesn't come with the
> performance hit associated with exceptions.  It's extensible, and can be
> easily extended to support the various ways LLDB needs to construct errors
> and error messages.
> >   • Would need to first rename lldb::Error to
> LLDBError so that te conversion from LLDBError to llvm::Error could be done
> incrementally.
> >   • Risk: 7
> >   • Impact: 7
> >   • Difficulty / Effort: 8
>
> We must be very careful here. Nothing can crash LLDB and adding something
> that will be known to crash in some cases can only be changed if there is a
> test that can guarantee that it won't crash. assert() calls in a shared
> library like LLDB are not OK and shouldn't fire. Even if they do, when
> asserts are off, then it shouldn't crash LLDB. We have made efforts to only
> use asserts in LLDB for things that really can't happen, but for things
> like constructing a StringRef with NULL is one example of why I don't want
> to use certain classes in LLVM. If we can remove the crash threat, then
> lets use them. But many people firmly believe that asserts belong in llvm
> and clang code and I don't agree. Also many asserts are in header files so
> even if you build llvm and clang with asserts off, but then build our
> project that uses LLVM with asserts on, you get LLVM and clang asserts when
> you don't want them.
>
We can probably add something to llvm::Error to make it not assert but to
do something else instead.  Something that would be 

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

[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 difficult cases?  In
> https://reviews.llvm.org/D24591 a number of ideas were discussed.  We
> started getting to this idea towards the end, about a separate tool which
> has an interface independent of the command line interface and which can be
> used to test.  lldb-mi was mentioned.  While I have serious concerns about
> lldb-mi due to its poorly written and tested codebase, I do agree in
> principle with the methodology.  In fact, this is the entire philosophy
> behind lit as used with LLVM, clang, lld, etc.
>
> We have a public API... Why are we going to go and spend _any_ time on
> doing anything else? I just don't get it. What a waste of time. We have a
> public API. Lets use it. Not simple enough for people? Tough. Testing a
> debugger should be done using the public API except when we are actually
> trying to test the LLDB command line in pexpect like tests. Those and only
> those are fine to covert over to using LIT and use text scraping. But 95%
> of our testing should be done using the API that our IDEs use. Using MI?
> Please no.


FWIW, I agree with you about mi.

That said, the public api is problematic.  Here you've got an API which,
once you do something to, is set in stone forever.  And yet in order to
test something, you have to add it to the API.  So now, in order to test
something, you have to make a permanent change to a public API that can
never be undone.

It's also a public facing API, when a lot of the stuff  we need to be able
to look at and inspect is not really suitable for public consumption.

If something is a public API that can never be changed once it's added,
then there should be an extremely strict review process in order to add
something to it.  It should be VERY HARD to modify (it's currently not,
which is a debate for another day, but anyway...).  And yet that's
fundamentally incompatible with having tests be easy to write.  When it's
hard to add the thing you need to add in order to write the test, then it's
hard to write the test.

Furthermore, with a system such as the one I proposed, you could even run
tests with LLDB_DISABLE_PYTHON.  IDK about you, but that would be *amazing*
from my point of view.  Even though I spent months making Python 3 work, I
would be happy to burn it all with fire and go back to just Python 2 if we
had a viable testing strategy.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[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/groundwork/plumbing code/... on the
> llvm.org side of the fence, but that code is a no-op there. The real
> grunt work happens on the Swift support. It's just architecturally sound to
> have non-Swift-specific bits happen on the llvm.org side. When that
> happens, I have no reasonable way (in the current model) to test the
> groundwork - it's just an intricate no-op that doesn't get activated.
>
> There are tests. They are on a different repo. It's not great, I'll admit.
> But right now, I would have to design an API around those bits even though
> I don't need one, or add commands I don't want "just" for testing. That is
> polluting a valuable user-facing resource with implementation details. I
> would gladly jump on a testing infrastructure that lets me write tests for
> this kind of code without extra API/commands.
>

Part of the problem is just that I think we don't have the tools we need to
write effective tests.  We have a lot of tests that only work on a
particular platform, or with a particular language runtime, or all these
different variables that affect the configurations under which the test
should pass.  In an ideal world we would be able to test the lion's share
of the debugger on any platform.  The only thing that's platform specific
is really the loader.  But maybe we have a huge block of code that itself
is not platform specific, but only gets run as a child of some platform
specific branch.  Now coverage of that platform-inedpenent branch is
limited or non-existant, because it depends on being able to have juuust
the right setup to tickle the debugger into running it.

So I just want to re-iterate that I don't think anyone is to blame, we just
don't have the right tools that we need.  I think the separate tools that I
mentioned could go a long way to rectifying that, because you can skip past
all of the platform specific aspects and test the code that runs behind
them.

Of course, you'd still have your full integration tests, but you'd now have
much fewer.  And when they fail, you'd have a pretty good idea where to
look because presumably the failure would be specific to some bit of
platform specific functionality.

I remmeber one case where TestUnsigned failed on Windows but TestSigned
passed.  And when we ultimately tracked down the error, it had absolutely
nothing to do with signed-ness.  Because there were too many layers in
between the test and the functionality being tested.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[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 ideas for where we go 
> from here.  I have a large list of ideas (more ideas than time, sadly) that 
> I've been collecting over the past few weeks, so I figured I would throw them 
> out in the open for discussion.
> 
> I’ve grouped the areas for improvement into 3 high level categories.
> 
> De-inventing the wheel - We should use more code from LLVM, and delete code 
> in LLDB where LLVM provides a solution.  In cases where there is an LLVM 
> thing that is *similar* to what we need, we should extend the LLVM thing to 
> support what we need, and then use it.  Following are some areas I've 
> identified.  This list is by no means complete.  For each one, I've given a 
> personal assessment of how likely it is to cause some (temporary) hiccups, 
> how much it would help us in the long run, and how difficult it would be to 
> do.  Without further ado:
> Use llvm::Regex instead of lldb::Regex
> llvm::Regex doesn’t support enhanced mode.  Could we add support for this to 
> llvm::Regex?
> Risk: 6
> Impact: 3
> Difficulty / Effort: 3  (5 if we have to add enhanced mode support)
> 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: 4
> Impact: 5
> Difficulty / Effort: 7
> Use llvm::Error instead of lldb::Error
> llvm::Error is an error class that *requires* you to check whether it 
> succeeded or it will assert.

I assume that assertion would be stripped in Release builds?
We have our own lldbassert() macro currently, which assert()s in Debug mode, 
but in Release mode produces an error message and continues
It would be great if llvm::Error allowed us to plug that in..

>   In a way, it's similar to a C++ exception, except that it doesn't come with 
> the performance hit associated with exceptions.  It's extensible, and can be 
> easily extended to support the various ways LLDB needs to construct errors 
> and error messages.
> Would need to first rename lldb::Error to LLDBError so that te conversion 
> from LLDBError to llvm::Error could be done incrementally.
> Risk: 7
> Impact: 7
> Difficulty / Effort: 8
> StringRef instead of const char *, len everywhere
> Can do most common string operations in a way that is guaranteed to be safe.
> Reduces string manipulation algorithm complexity by an order of magnitude.
> Can potentially eliminate tens of thousands of string copies across the 
> codebase.
> Simplifies code.
> Risk: 3
> Impact: 8
> Difficulty / Effort: 7
> ArrayRef instead of const void *, len everywhere
> Same analysis as StringRef
> MutableArrayRef instead of void *, len everywhere
> Same analysis as StringRef

I don't think we have a lot of those - IIRC, it's mostly in the SB API where 
SWIG is supposed to map it back to a Python string

> Delete ConstString, use a modified StringPool that is thread-safe.
> StringPool is a non thread-safe version of ConstString.
> Strings are internally refcounted so they can be cleaned up when they are no 
> longer used.  ConstStrings are a large source of memory in LLDB, so 
> ref-counting and removing stale strings has the potential to be a huge 
> savings.
> Risk: 2
> Impact: 9
> Difficulty / Effort: 6
> thread_local instead of lldb::ThreadLocal
> This fixes a number of bugs on Windows that cannot be fixed otherwise, as 
> they require compiler support.
> Some other compilers may not support this yet?
> Risk: 2
> Impact: 3
> Difficulty: 3
> Use llvm::cl for the command line arguments to the primary lldb executable.
> Risk: 2
> Impact: 3
> Difficulty / Effort: 4
> Testing - Our testing infrastructure is unstable, and our test coverage is 
> lacking.  We should take steps to improve this.
> Port as much as possible to lit
> Simple tests should be trivial to port to lit today.  If nothing else this 
> serves as a proof of concept while increasing the speed and stability of the 
> test suite, since lit is a more stable harness.
> 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 difficult cases?  In https://reviews.llvm.org/D24591 
>  a number of ideas were discussed.  We 
> started getting to this idea towards the end, about a separate tool which has 
> an interface independent of the command line interface and which can be used 
> to test.  lldb-mi was mentioned.  While I have serious concerns about lldb-mi 
> due to its poorly written and tested codebase, I do agree in principle 

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

[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 operators.
>  2. Interoperates nicely with many existing llvm utility classes
>  3. Risk: 4
>  4. Impact: 5
>  5. Difficulty / Effort: 7
>
>
> I don't like that llvm's stringstream needs to be babied to make it
> produce its string.  You have to wrap it and then flush it and then read
> the string.  Maybe a subclass could be made that wraps its own string and
> flushes automatically on read?
>

You do have to wrap it.  But if you call llvm::raw_string_ostream::str(),
it will internally flush before it returns the thing.  So if you write:

std::string s;
llvm::raw_string_ostream stream(s);
stream << "foo";
return stream.str();

then the code will be correct.  It's still a bit more annoying then if the
string were automatically part of the stream though, so there's probably a
clean way to design a version of it that owns the string.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] LLDB Evolution - Final Form

[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)
that I've been collecting over the past few weeks, so I figured I would
throw them out in the open for discussion.

I’ve grouped the areas for improvement into 3 high level categories.


   1.

   De-inventing the wheel - We should use more code from LLVM, and delete
   code in LLDB where LLVM provides a solution. In cases where there is an
   LLVM thing that is *similar* to what we need, we should extend the LLVM
   thing to support what we need, and then use it. Following are some areas
   I've identified. This list is by no means complete. For each one, I've
   given a personal assessment of how likely it is to cause some (temporary)
   hiccups, how much it would help us in the long run, and how difficult it
   would be to do. Without further ado:
   1.

  Use llvm::Regex instead of lldb::Regex
  1.

 llvm::Regex doesn’t support enhanced mode.  Could we add support
 for this to llvm::Regex?
 2.

 Risk: 6
 3.

 Impact: 3
 4.

 Difficulty / Effort: 3 (5 if we have to add enhanced mode support)
 2.

  Use llvm streams instead of lldb::StreamString
  1.

 Supports output re-targeting (stderr, stdout, std::string, etc),
 printf style formatting, and type-safe streaming operators.
 2.

 Interoperates nicely with many existing llvm utility classes
 3.

 Risk: 4
 4.

 Impact: 5
 5.

 Difficulty / Effort: 7
 3.

  Use llvm::Error instead of lldb::Error
  1.

 llvm::Error is an error class that *requires* you to check whether
 it succeeded or it will assert. In a way, it's similar to a
C++ exception,
 except that it doesn't come with the performance hit associated with
 exceptions. It's extensible, and can be easily extended to support the
 various ways LLDB needs to construct errors and error messages.
 2.

 Would need to first rename lldb::Error to LLDBError so that te
 conversion from LLDBError to llvm::Error could be done
 incrementally.
 3.

 Risk: 7
 4.

 Impact: 7
 5.

 Difficulty / Effort: 8
 4.

  StringRef instead of const char *, len everywhere
  1.

 Can do most common string operations in a way that is guaranteed
 to be safe.
 2.

 Reduces string manipulation algorithm complexity by an order of
 magnitude.
 3.

 Can potentially eliminate tens of thousands of string copies
 across the codebase.
 4.

 Simplifies code.
 5.

 Risk: 3
 6.

 Impact: 8
 7.

 Difficulty / Effort: 7
 5.

  ArrayRef instead of const void *, len everywhere
  1.

 Same analysis as StringRef
 6.

  MutableArrayRef instead of void *, len everywhere
  1.

 Same analysis as StringRef
 7.

  Delete ConstString, use a modified StringPool that is thread-safe.
  1.

 StringPool is a non thread-safe version of ConstString.
 2.

 Strings are internally refcounted so they can be cleaned up when
 they are no longer used.  ConstStrings are a large source of
 memory in LLDB, so ref-counting and removing stale strings has the
 potential to be a huge savings.
 3.

 Risk: 2
 4.

 Impact: 9
 5.

 Difficulty / Effort: 6
 8.

  thread_local instead of lldb::ThreadLocal
  1.

 This fixes a number of bugs on Windows that cannot be fixed
 otherwise, as they require compiler support.
 2.

 Some other compilers may not support this yet?
 3.

 Risk: 2
 4.

 Impact: 3
 5.

 Difficulty: 3
 9.

  Use llvm::cl for the command line arguments to the primary lldb
  executable.
  1.

 Risk: 2
 2.

 Impact: 3
 3.

 Difficulty / Effort: 4
 2.

   Testing - Our testing infrastructure is unstable, and our test coverage
   is lacking. We should take steps to improve this.
   1.

  Port as much as possible to lit
  1.

 Simple tests should be trivial to port to lit today.  If nothing
 else this serves as a proof of concept while increasing the speed and
 stability of the test suite, since lit is a more stable harness.
 2.

  Separate testing tools
  1.

 One question that remains open is how to represent the complicated
 needs of a debugger in lit tests.  

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

[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 will clean up my full script and send it to you 
>> if the following does not provide enough information, thanks much.
>> 
>> def vtable_addr (vtableSymbol):
>>return vtableSymbol.addr.section.file_addr + vtableSymbol.addr.offset + 
>> 0x10
> 
> You actually want to get the load address when reading from memory. This 
> should be:
> 
> def vtable_addr (vtableSymbol, target):
>return vtableSymbol.addr.GetLoadAddress(target) + 0x10

If you actually wanted the file address of vtableSymbol's address, then you 
would do this:

def vtable_addr (vtableSymbol, target):
   return vtableSymbol.addr.GetFileAddress() + 0x10

No need to do the section + offset math yourself.

> 
>> 
>> 
>> vtableAddr, type=, value=0x1000f
>> vtableAddr-8, type=, value=0x10007
>> Traceback (most recent call last):
>>  File "", line 1, in 
>>  File "/home/leikong/repo/WindowsFabric/build.prod/test/fabdbg.py", line 
>> 199, in findall
>>findtypes(pattern,ignorePureVirtualType)
>>  File "/home/leikong/repo/WindowsFabric/build.prod/test/fabdbg.py", line 
>> 156, in findtypes
>>if ignorePureVirtualType and has_pure_virtual(vtableAddr, 
>> pureVirtualFuncs) :
>>  File "/home/leikong/repo/WindowsFabric/build.prod/test/fabdbg.py", line 
>> 100, in has_pure_virtual
>>vtableEndAddr = lldb.process.ReadPointerFromMemory(vtableAddr-8, error)
>>  File "/home/leikong/bin/lldb/lib/python2.7/site-packages/lldb/__init__.py", 
>> line 9418, in ReadPointerFromMemory
>>return _lldb.SBProcess_ReadPointerFromMemory(self, addr, error)
>> OverflowError: in method 'SBProcess_ReadPointerFromMemory', argument 2 of 
>> type 'lldb::addr_t'
>> 
>> From: Greg Clayton
>> Sent: Monday, September 19, 2016 09:12 AM
>> To: Lei Kong
>> Cc: Jim Ingham; lldb-dev@lists.llvm.org
>> Subject: 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, 2016, at 7:39 PM, Lei Kong via lldb-dev 
>>>  wrote:
>>> 
>>> I tried printing error.descryption, but it didn't work, because when the 
>>> error happens, it seems ReadPointerFromMemory never returned to my code.
>>> 
>>> 
>>> read from address 01223f68
>>> Traceback (most recent call last):
>>>  File "", line 1, in 
>>>  File "/home/leikong/repo/WindowsFabric/build.prod/test/fabdbg.py", line 
>>> 289, in findall
>>>findtypes(pattern,ignorePureVirtualType)
>>>  File "/home/leikong/repo/WindowsFabric/build.prod/test/fabdbg.py", line 
>>> 246, in findtypes
>>>if ignorePureVirtualType and has_pure_virtual(vtableAddr, 
>>> pureVirtualFuncs) :
>>>  File "/home/leikong/repo/WindowsFabric/build.prod/test/fabdbg.py", line 
>>> 190, in has_pure_virtual
>>>vtableEndAddr = lldb.process.ReadPointerFromMemory(vtableAddr-8, error)
>>>  File 
>>> "/home/leikong/bin/lldb/lib/python2.7/site-packages/lldb/__init__.py", line 
>>> 9418, in ReadPointerFromMemory
>>>return _lldb.SBProcess_ReadPointerFromMemory(self, addr, error)
>>> OverflowError: in method 'SBProcess_ReadPointerFromMemory', argument 2 of 
>>> type 'lldb::addr_t'
>>> 
>>> 
 Subject: Re: [lldb-dev] OverflowError: in method 
 'SBProcess_ReadPointerFromMemory', argument 2 of type 'lldb::addr_t'
 From: jing...@apple.com
 Date: Fri, 16 Sep 2016 17:12:24 -0700
 CC: lldb-dev@lists.llvm.org
 To: leik...@msn.com
 
 You passed an error into ReadPointerFromMemory. In the cases where you 
 aren't getting what you expect, what does that error say?
 
 Jim
 
> On Sep 16, 2016, at 5:06 PM, Lei Kong via lldb-dev 
>  wrote:
> 
> I ran into the error in the subject when running a python script with 
> "script myfile.myscript()".
> 
> The value addr_t parameter used is 0x01223f68, the following 
> works fine:
> 
> (lldb) scr
> Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or 
> Ctrl-D.
 e = lldb.SBError()
 ptr = lldb.process.ReadPointerFromMemory(0x01223f68, e)
 print ptr
> 0
 
> 
> Any suggestion how to further investigate? Thanks.
> 
> myfile.myscript() calls the following function in a loop (iterate through 
> all vtable symbols), which contains the call ReadPointerFromMemory.
> 
> 

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

[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 vtable_addr (vtableSymbol):
return vtableSymbol.addr.section.file_addr + vtableSymbol.addr.offset + 0x10


vtableAddr, type=, value=0x1000f
vtableAddr-8, type=, value=0x10007
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/leikong/repo/WindowsFabric/build.prod/test/fabdbg.py", line 199, 
in findall
findtypes(pattern,ignorePureVirtualType)
  File "/home/leikong/repo/WindowsFabric/build.prod/test/fabdbg.py", line 156, 
in findtypes
if ignorePureVirtualType and has_pure_virtual(vtableAddr, pureVirtualFuncs) 
:
  File "/home/leikong/repo/WindowsFabric/build.prod/test/fabdbg.py", line 100, 
in has_pure_virtual
vtableEndAddr = lldb.process.ReadPointerFromMemory(vtableAddr-8, error)
  File "/home/leikong/bin/lldb/lib/python2.7/site-packages/lldb/__init__.py", 
line 9418, in ReadPointerFromMemory
return _lldb.SBProcess_ReadPointerFromMemory(self, addr, error)
OverflowError: in method 'SBProcess_ReadPointerFromMemory', argument 2 of type 
'lldb::addr_t'

From: Greg Clayton
Sent: Monday, September 19, 2016 09:12 AM
To: Lei Kong
Cc: Jim Ingham; 
lldb-dev@lists.llvm.org
Subject: 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, 2016, at 7:39 PM, Lei Kong via lldb-dev  
> wrote:
>
> I tried printing error.descryption, but it didn't work, because when the 
> error happens, it seems ReadPointerFromMemory never returned to my code.
>
>
> read from address 01223f68
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/home/leikong/repo/WindowsFabric/build.prod/test/fabdbg.py", line 
> 289, in findall
> findtypes(pattern,ignorePureVirtualType)
>   File "/home/leikong/repo/WindowsFabric/build.prod/test/fabdbg.py", line 
> 246, in findtypes
> if ignorePureVirtualType and has_pure_virtual(vtableAddr, 
> pureVirtualFuncs) :
>   File "/home/leikong/repo/WindowsFabric/build.prod/test/fabdbg.py", line 
> 190, in has_pure_virtual
> vtableEndAddr = lldb.process.ReadPointerFromMemory(vtableAddr-8, error)
>   File "/home/leikong/bin/lldb/lib/python2.7/site-packages/lldb/__init__.py", 
> line 9418, in ReadPointerFromMemory
> return _lldb.SBProcess_ReadPointerFromMemory(self, addr, error)
> OverflowError: in method 'SBProcess_ReadPointerFromMemory', argument 2 of 
> type 'lldb::addr_t'
>
>
> > Subject: Re: [lldb-dev] OverflowError: in method 
> > 'SBProcess_ReadPointerFromMemory', argument 2 of type 'lldb::addr_t'
> > From: jing...@apple.com
> > Date: Fri, 16 Sep 2016 17:12:24 -0700
> > CC: lldb-dev@lists.llvm.org
> > To: leik...@msn.com
> >
> > You passed an error into ReadPointerFromMemory. In the cases where you 
> > aren't getting what you expect, what does that error say?
> >
> > Jim
> >
> > > On Sep 16, 2016, at 5:06 PM, Lei Kong via lldb-dev 
> > >  wrote:
> > >
> > > I ran into the error in the subject when running a python script with 
> > > "script myfile.myscript()".
> > >
> > > The value addr_t parameter used is 0x01223f68, the following 
> > > works fine:
> > >
> > > (lldb) scr
> > > Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or 
> > > Ctrl-D.
> > > >>> e = lldb.SBError()
> > > >>> ptr = lldb.process.ReadPointerFromMemory(0x01223f68, e)
> > > >>> print ptr
> > > 0
> > > >>>
> > >
> > > Any suggestion how to further investigate? Thanks.
> > >
> > > myfile.myscript() calls the following function in a loop (iterate through 
> > > all vtable symbols), which contains the call ReadPointerFromMemory.
> > >
> > > def dump_vtbl(vtableAddr) :
> > > error = lldb.SBError()
> > > vtableEndAddr = lldb.process.ReadPointerFromMemory(vtableAddr+8, error)
> > > if not error.success :
> > > return False
> > > print "vtable: [%0.16x, %0.16x)" % (vtableAddr, vtableEndAddr)
> > > for addr in range(vtableAddr, vtableEndAddr, 8) :
> > > print "read from address %.016x" % addr
> > > try:
> > > funcAddr = lldb.process.ReadPointerFromMemory(addr, error)
> > > except:
> > > sys.exc_clear()
> > > continue
> > > if not error.success :
> > > continue
> > >
> > > ___
> > > lldb-dev mailing list
> > > lldb-dev@lists.llvm.org
> > > 

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

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=26261

Todd Fiala  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Todd Fiala  ---
I'm not seeing this fail on r281913.  Calling this good.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=29046

Todd Fiala  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Todd Fiala  ---
Fixed in r281913.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=29045

Todd Fiala  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Todd Fiala  ---
Fixed in r281913.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[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)
> 
> 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, at 7:39 PM, Lei Kong via lldb-dev  
>> wrote:
>> 
>> I tried printing error.descryption, but it didn't work, because when the 
>> error happens, it seems ReadPointerFromMemory never returned to my code.
>> 
>> 
>> read from address 01223f68
>> Traceback (most recent call last):
>>  File "", line 1, in 
>>  File "/home/leikong/repo/WindowsFabric/build.prod/test/fabdbg.py", line 
>> 289, in findall
>>findtypes(pattern,ignorePureVirtualType)
>>  File "/home/leikong/repo/WindowsFabric/build.prod/test/fabdbg.py", line 
>> 246, in findtypes
>>if ignorePureVirtualType and has_pure_virtual(vtableAddr, 
>> pureVirtualFuncs) :
>>  File "/home/leikong/repo/WindowsFabric/build.prod/test/fabdbg.py", line 
>> 190, in has_pure_virtual
>>vtableEndAddr = lldb.process.ReadPointerFromMemory(vtableAddr-8, error)
>>  File "/home/leikong/bin/lldb/lib/python2.7/site-packages/lldb/__init__.py", 
>> line 9418, in ReadPointerFromMemory
>>return _lldb.SBProcess_ReadPointerFromMemory(self, addr, error)
>> OverflowError: in method 'SBProcess_ReadPointerFromMemory', argument 2 of 
>> type 'lldb::addr_t'
>> 
>> 
>>> Subject: Re: [lldb-dev] OverflowError: in method 
>>> 'SBProcess_ReadPointerFromMemory', argument 2 of type 'lldb::addr_t'
>>> From: jing...@apple.com
>>> Date: Fri, 16 Sep 2016 17:12:24 -0700
>>> CC: lldb-dev@lists.llvm.org
>>> To: leik...@msn.com
>>> 
>>> You passed an error into ReadPointerFromMemory. In the cases where you 
>>> aren't getting what you expect, what does that error say?
>>> 
>>> Jim
>>> 
 On Sep 16, 2016, at 5:06 PM, Lei Kong via lldb-dev 
  wrote:
 
 I ran into the error in the subject when running a python script with 
 "script myfile.myscript()".
 
 The value addr_t parameter used is 0x01223f68, the following works 
 fine:
 
 (lldb) scr
 Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
>>> e = lldb.SBError()
>>> ptr = lldb.process.ReadPointerFromMemory(0x01223f68, e)
>>> print ptr
 0
>>> 
 
 Any suggestion how to further investigate? Thanks.
 
 myfile.myscript() calls the following function in a loop (iterate through 
 all vtable symbols), which contains the call ReadPointerFromMemory.
 
 def dump_vtbl(vtableAddr) :
 error = lldb.SBError()
 vtableEndAddr = lldb.process.ReadPointerFromMemory(vtableAddr+8, error)
 if not error.success :
 return False
 print "vtable: [%0.16x, %0.16x)" % (vtableAddr, vtableEndAddr)
 for addr in range(vtableAddr, vtableEndAddr, 8) :
 print "read from address %.016x" % addr
 try:
 funcAddr = lldb.process.ReadPointerFromMemory(addr, error)
 except:
 sys.exc_clear()
 continue
 if not error.success :
 continue
 
 ___
 lldb-dev mailing list
 lldb-dev@lists.llvm.org
 http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>> 
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[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, at 7:39 PM, Lei Kong via lldb-dev  
> wrote:
> 
> I tried printing error.descryption, but it didn't work, because when the 
> error happens, it seems ReadPointerFromMemory never returned to my code.
>  
>  
> read from address 01223f68
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/home/leikong/repo/WindowsFabric/build.prod/test/fabdbg.py", line 
> 289, in findall
> findtypes(pattern,ignorePureVirtualType)
>   File "/home/leikong/repo/WindowsFabric/build.prod/test/fabdbg.py", line 
> 246, in findtypes
> if ignorePureVirtualType and has_pure_virtual(vtableAddr, 
> pureVirtualFuncs) :
>   File "/home/leikong/repo/WindowsFabric/build.prod/test/fabdbg.py", line 
> 190, in has_pure_virtual
> vtableEndAddr = lldb.process.ReadPointerFromMemory(vtableAddr-8, error)
>   File "/home/leikong/bin/lldb/lib/python2.7/site-packages/lldb/__init__.py", 
> line 9418, in ReadPointerFromMemory
> return _lldb.SBProcess_ReadPointerFromMemory(self, addr, error)
> OverflowError: in method 'SBProcess_ReadPointerFromMemory', argument 2 of 
> type 'lldb::addr_t'
> 
>  
> > Subject: Re: [lldb-dev] OverflowError: in method 
> > 'SBProcess_ReadPointerFromMemory', argument 2 of type 'lldb::addr_t'
> > From: jing...@apple.com
> > Date: Fri, 16 Sep 2016 17:12:24 -0700
> > CC: lldb-dev@lists.llvm.org
> > To: leik...@msn.com
> > 
> > You passed an error into ReadPointerFromMemory. In the cases where you 
> > aren't getting what you expect, what does that error say?
> > 
> > Jim
> > 
> > > On Sep 16, 2016, at 5:06 PM, Lei Kong via lldb-dev 
> > >  wrote:
> > > 
> > > I ran into the error in the subject when running a python script with 
> > > "script myfile.myscript()".
> > >  
> > > The value addr_t parameter used is 0x01223f68, the following 
> > > works fine:
> > > 
> > > (lldb) scr
> > > Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or 
> > > Ctrl-D.
> > > >>> e = lldb.SBError()
> > > >>> ptr = lldb.process.ReadPointerFromMemory(0x01223f68, e)
> > > >>> print ptr
> > > 0
> > > >>> 
> > >  
> > > Any suggestion how to further investigate? Thanks.
> > >  
> > > myfile.myscript() calls the following function in a loop (iterate through 
> > > all vtable symbols), which contains the call ReadPointerFromMemory.
> > >  
> > > def dump_vtbl(vtableAddr) :
> > > error = lldb.SBError()
> > > vtableEndAddr = lldb.process.ReadPointerFromMemory(vtableAddr+8, error)
> > > if not error.success :
> > > return False
> > > print "vtable: [%0.16x, %0.16x)" % (vtableAddr, vtableEndAddr)
> > > for addr in range(vtableAddr, vtableEndAddr, 8) :
> > > print "read from address %.016x" % addr
> > > try:
> > > funcAddr = lldb.process.ReadPointerFromMemory(addr, error)
> > > except:
> > > sys.exc_clear()
> > > continue
> > > if not error.success :
> > > continue
> > > 
> > > ___
> > > lldb-dev mailing list
> > > lldb-dev@lists.llvm.org
> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> > 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev