Re: [lldb-dev] [PATCH] D24591: [LIT] First pass of LLDB LIT support

2016-09-15 Thread Zachary Turner via lldb-dev 
lldb-commits to bcc, lldb-dev to cc.

> The biggest feature I see missing here is the ability to run tests
remotely. Remote debugging is the most important use case for our team, and
now we have a number of (experimental) bots running the remote test suite.
We want to make sure we can debug correctly when the host and target have
different architectures

That is a good point.  I thought about this a little bit and I believe I
have a solution to most of the issues you would face when running a remote
test suite, but perhaps it would be better to take that to a different
thread on lldb-dev rather than on this commit.  So I'm taking lldb-commits
off of this thread and adding lldb-dev.   Responses inline.

On Thu, Sep 15, 2016 at 4:02 AM Pavel Labath  wrote:



>  - the test suite needs to know how to connect to the remote target
> (mostly it's just executing three commands: `platform select XXX`,
> `platform connect` and `platform settings --working-dir YYY`), but it can
> get a bit more complicated in some cases (if we need to install shared
> libraries along with the main executable, if it involves the test
> executable writing something to a file, etc.)

This seems like the easiest of the problems to solve, so I'm mentioning it
first.  I can imagine a couple of command line options to the lldb
executable itself that allow one to configure remote debugging from the
command line.  Then, we could provide one CMake target for each remote
platform.  check-lldb-remote-android, check-lldb-remote-fizzbuzz,
whatever.  And you could configure all of these at CMake time with one
command.  Like cmake -DLLDB_TEST_REMOTE_TARGETS=android,fizzbuzz,etc.
Internally, each target's CMake logic could configure some appropriate
variables that would be picked up by lit so that the lit substitution for
running lldb would supply the appropriate command line to configure the
remote target.

 - this includes the need to pass funny compiler switches based on the
target (some android targets can only run `-pie` executables, some cannot
run `-pie` executables at all).
 This should be handled the same way as above.  Configuring the lit
substitutions for the compiler invocation can depend on which cmake target
you're running lit through.  ninja check-lldb-remote-android could define
one set of lit substitutions, and another target could define another.  Is
this sufficient?  Is it easy to define a mapping between the set of all
remote targets and the set of all command line flag combinations?

- we need to be able to fully specify the toolchain used to compile the
> target executables (specifically, we should not assume the host compiler)
>
Will you want a single run of the test suite to use multiple compilers, or
can we assume there is only 1 compiler for a given cmake output directory?
I think we can assume the latter since even now we only have 1 cmake
variable `LLDB_TEST_COMPILER`, but let me know if this is a wrong assumption


>
> - we need to be careful about strong cmake integration. The same lldb
> binary is capable of debugging all kinds of targets. We should not require
> a fresh cmake build to run the test suite against multiple targets. If we
> need to switch cmake options (`LLDB_TEST_COMPILER`, `LLDB_TEST_ARCH`,
> `LLDB_TEST_URL` or similar) and it does not trigger a rebuild then it's
> usable, but slightly inpractical. For us, it would be best to be able a
> fire off a remote test with a single command (like we can do now).
>
See first response.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Problem with watchpoints

2016-09-15 Thread Ted Woodward via lldb-dev 
I found another issue, Daniel:

GDBRemoteCommunicationClient::GetWatchpointSupportInfo calls 
SendPacketAndWaitForResponse, and assumes that a return of 
PacketResult::Success means that qWatchpointSupportInfo is handled by the 
remote server. That's not true; a null response also returns 
PacketResult::Success. It also needs to check that response.Empty() isn't true.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


-Original Message-
From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Jim Ingham 
via lldb-dev
Sent: Monday, September 12, 2016 2:01 PM
To: Daniel Noland 
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Problem with watchpoints


> On Sep 12, 2016, at 11:53 AM, Daniel Noland  wrote:
> 
> 
> 
> On 09/12/2016 11:30 AM, Jim Ingham wrote:
>> 
>>> On Sep 9, 2016, at 7:33 PM, Daniel Noland  wrote:
>>> 
>>> Yes, that was pretty much my assessment when I read through the code.
>>> 
>>> My existing patch (which I will post when I get home) takes a very 
>>> conservative approach and only modifies what is strictly necessary to make 
>>> the callback feature work.
>>> 
>>> That said, I found myself copy / paste / slight changing a fair bit of code 
>>> to make it work.  Usually a very bad sign.
>>> 
>>> If we can agree that a more aggressive refactor is desirable I would prefer 
>>> that route.
>> 
>> This work really needs to be done, and shouldn't even be all that hard.  So 
>> putting too much effort into the current implementation seems throw-away 
>> work.  It's okay when small changes make useful functionality available, but 
>> not the right general direction.  If you are interested in taking a more 
>> comprehensive change on, that would be great!
>> 
> I am actually very relieved to hear that!
> 
> I have a strong personal motivation to see very robust watchpoint 
> functionality in LLDB (the last two years of my life will be largely 
> wasted without it).  If the community is open to a more aggressive 
> change I will be very happy to put in work on this front.
> 
>>> 
>>> It may be worth looking at the GDB Python API 
>>> (https://sourceware.org/gdb/onlinedocs/gdb/Breakpoints-In-Python.html#Breakpoints-In-Python).
>>>   Watchpoints are just a species of breakpoint in that implementation.
>>> 
>>> I have done extensive work with that API, and while there are things I 
>>> would do very differently, I generally consider it to be fairly good.
>>> 
>> 
>> From the API perspective, watchpoints and breakpoints are equivalent, except 
>> where the brokenness of the implementation shows through.
>> 
>>> In fact, I think that the LLDB SB API could profit quite a bit from several 
>>> of the things GDB has done on that front.  That is particularly true with 
>>> respect to symbols, variables, and frames.  That subject likely deserves a 
>>> different thread.
>> 
>> Within the constraints of maintaining support for the extant SB API's, we 
>> can certainly look to improving the breakpoint/watchpoint interface.  But 
>> the most logical approach seems to me to be to move the watchpoints over to 
>> the sharing the extant and pretty functional breakpoint implementation 
>> first, and then see what we can more efficiently add stuff to both.
>> 
> I agree.  I plan to start exactly as you suggest.

Excellent, feel free to pester us with whatever questions you have as you 
proceed.  This is a piece of work that really does need to get done so I'm 
happy to see somebody taking it on.

> 
> My main thought here (which should likely get a different thread) is 
> that, having worked with the GDB and LLDB api for a while now, I feel 
> pretty strongly that GDB has a better cleaner handling of variable 
> names, scopes, frames, and values than LLDB seems to offer (I would 
> love to be wrong about this btw), and that adopting / adapting some of 
> those abstractions may significantly improve the break/watchpoint api.
> 
> I should be able to say that with more authority after giving the 
> implementation more careful study.

Great!  I look forward to your ideas.  One note is that we have promised not to 
break compatibility with the current SB API's till we decide to do a whole 
scale revision.  So for now whatever we change needs to fit within the current 
schema.

> 
>> We also have to be a little careful about taking things too directly from 
>> gdb due to licensing issues.
>> 
> Good point about licensing.  That said, if the concern is duplicating 
> the implementation, I doubt that I could do it if I tried :)
> 
> Duplication of the API should not be an issue either as I plan to 
> strictly adhere to the existing SB api.
> 

That sounds right.

Jim


>> Jim
>> 
>> 
>>> 
>>> \author{Dan}
>>> 
>>> On Fri, Sep 9, 2016 at 3:52 PM, Jim Ingham  wrote:
>>> The main problem with the watchpoint code is that it doesn't share nearly 
>>> as much of the implementation of options and callback h

Re: [lldb-dev] [PATCH] D24591: [LIT] First pass of LLDB LIT support

2016-09-15 Thread Pavel Labath via lldb-dev 
On 15 September 2016 at 16:15, Zachary Turner  wrote:
> lldb-commits to bcc, lldb-dev to cc.
>
>> The biggest feature I see missing here is the ability to run tests
>> remotely. Remote debugging is the most important use case for our team, and
>> now we have a number of (experimental) bots running the remote test suite.
>> We want to make sure we can debug correctly when the host and target have
>> different architectures
>
> That is a good point.  I thought about this a little bit and I believe I
> have a solution to most of the issues you would face when running a remote
> test suite, but perhaps it would be better to take that to a different
> thread on lldb-dev rather than on this commit.  So I'm taking lldb-commits
> off of this thread and adding lldb-dev.   Responses inline.
>
> On Thu, Sep 15, 2016 at 4:02 AM Pavel Labath  wrote:
>
>
>>
>>  - the test suite needs to know how to connect to the remote target
>> (mostly it's just executing three commands: `platform select XXX`, `platform
>> connect` and `platform settings --working-dir YYY`), but it can get a bit
>> more complicated in some cases (if we need to install shared libraries along
>> with the main executable, if it involves the test executable writing
>> something to a file, etc.)
>
> This seems like the easiest of the problems to solve, so I'm mentioning it
> first.  I can imagine a couple of command line options to the lldb
> executable itself that allow one to configure remote debugging from the
> command line.  Then, we could provide one CMake target for each remote
> platform.  check-lldb-remote-android, check-lldb-remote-fizzbuzz, whatever.
> And you could configure all of these at CMake time with one command.  Like
> cmake -DLLDB_TEST_REMOTE_TARGETS=android,fizzbuzz,etc.  Internally, each
> target's CMake logic could configure some appropriate variables that would
> be picked up by lit so that the lit substitution for running lldb would
> supply the appropriate command line to configure the remote target.

I am happy to hear that you are thinking about the remote case. Yes,
this is definitely solvable, we just need to make sure the solution is
there, and it fits our needs.

>
>  - this includes the need to pass funny compiler switches based on the
> target (some android targets can only run `-pie` executables, some cannot
> run `-pie` executables at all).
>  This should be handled the same way as above.  Configuring the lit
> substitutions for the compiler invocation can depend on which cmake target
> you're running lit through.  ninja check-lldb-remote-android could define
> one set of lit substitutions, and another target could define another.  Is
> this sufficient?  Is it easy to define a mapping between the set of all
> remote targets and the set of all command line flag combinations?
The set of flags should be pretty easy to define, but I am a bit
worried about the idea of doing it in cmake. See below.

>
>> - we need to be able to fully specify the toolchain used to compile the
>> target executables (specifically, we should not assume the host compiler)
>
> Will you want a single run of the test suite to use multiple compilers, or
> can we assume there is only 1 compiler for a given cmake output directory?
> I think we can assume the latter since even now we only have 1 cmake
> variable `LLDB_TEST_COMPILER`, but let me know if this is a wrong assumption
Having one run of a test suite with a just a single compiler is fine.
dotest.py used to support more compilers, but that has been a long
time ago (I just checked it last week, it is not working anymore).
However, we do run the tests with multiple compilers from a single
output directory.

We do this by bypassing cmake and invoking dotest.py directly. Our
buildbot does that as well. Check out

you will see it does 6 test runs from a single cmake output directory
(if you click on the "stdio" link you can see the dotest.py commands
it invokes).

In my normal workflow I use "ninja check-lldb" to validate my changes,
but when I am working on a compiler-specific issue I do try it out
with the non-standard compiler by invoking dotest.py directly. I would
not want to need a fresh build of lldb for that as nothing within lldb
changes - I only need to the change compiler used to compile the test
executables. The same is true for android. Right now I am able to run
android x86 and android arm64 from the same build directory just by
specifying options to dotest.py. (Obviously I need to have a separate
build folder for the server component, but the python tests are run
against the client and the server is used only indirectly. Potentially
we could change that to run the test suite from the android build
folder, but then we would need a way to specify a path to the client
host build somewhere).

So, yes there is only one LLDB_TEST_COMPILER, but that is not the only
way to run the test suite. I think it's fine to hav

Re: [lldb-dev] lldb type summary provider - SBProcess is invalid

2016-09-15 Thread Jim Ingham via lldb-dev 
Yes, the "script" command always sets up the lldb.{process/thread/frame} 
regardless of whether its input is one-line or from the Script Input reader.  
The help for script should specify that.

Jim

> On Sep 14, 2016, at 10:24 PM, Lei Kong via lldb-dev  
> wrote:
> 
> Does the following qualify as "interactive usage"?  It seems using "process" 
> works in myfile.func(), or I was just lucky? Thanks.
>  
> (lldb) script myfile.func(args)
>  
> > Subject: Re: [lldb-dev] lldb type summary provider - SBProcess is invalid
> > From: gclay...@apple.com
> > Date: Wed, 14 Sep 2016 09:33:20 -0700
> > CC: egran...@apple.com; lldb-dev@lists.llvm.org
> > To: leik...@msn.com
> > 
> > 
> > > On Sep 13, 2016, at 9:50 PM, Lei Kong via lldb-dev 
> > >  wrote:
> > > 
> > > Thanks!
> > > SBValue.process works!
> > >  
> > > I have another script that I run manually to search process memory for 
> > > certain patterns, not a type summary provider, there is no SBValue passed 
> > > to my script, in such a case, how do I get current process?
> > >  
> > If this is python a command line command you are making, use the variant 
> > that takes an execution context:
> > 
> > def my_command(debugger, command, exe_ctx, result, dict):
> > # Always use the specified execution context to get the target, process
> > # thread and frame. If this command gets run from a breakpoint callback
> > # these will not match the debugger's selected target, the selected 
> > # process in the target, the selected thread in the process and the 
> > # selected frame in the thread.
> > target = exe_ctx.GetTarget()
> > process = exe_ctx.GetProcess()
> > thread = exe_ctx.GetThread()
> > frame = exe_ctx.GetFrame()
> > 
> > 
> > The execution context is explicitly specified for you.
> > 
> > > From: Enrico Granata
> > > Sent: Tuesday, September 13, 2016 10:31 AM
> > > To: Lei Kong
> > > Cc: lldb-dev@lists.llvm.org
> > > Subject: Re: [lldb-dev] lldb type summary provider - SBProcess is invalid
> > >  
> > > 
> > >> On Sep 13, 2016, at 10:02 AM, Lei Kong via lldb-dev 
> > >>  wrote:
> > >> 
> > >> I wrote a lldb type summary provider for wstring with 16bit wchar on 
> > >> Ubuntu 16.04.
> > >> 
> > >> Things work fine if I manually do the following in lldb:
> > >> 
> > >> (lldb) script import mytypes
> > >> (lldb) type summary add -F mytypes.wstring_SummaryProvider 
> > >> "std::__1::wstring"
> > >> 
> > >> I tried to make things easier with auto-loading by adding the following 
> > >> to .lldbinit:
> > >> 
> > >> script import mytypes
> > >> type summary add -F mytypes.wstring_SummaryProvider "std::__1::wstring"
> > >> 
> > >> Then I got a failure of "SBProcess is invalid" when printing a wstring 
> > >> variable.
> > >> 
> > >> My type summary function has the following, which I believe is where the 
> > >> error is encountered:
> > >> 
> > >> content = lldb.process.ReadMemory(bufferAddr, byteCount, error)
> > >> 
> > >> Maybe this is because "process" is not assigned yet when the type 
> > >> summary is added during auto-loading? Or this is a bug in lldb? Does 
> > >> anyone know how to work around this issue?
> > >> 
> > >> 
> > > 
> > > Good hunch :-)
> > > Maybe we should do a better job at documenting this, but 
> > > http://lldb.llvm.org/python-reference.html reads
> > > 
> > > "While extremely convenient, these variables (lldb.process et alia) have 
> > > a couple caveats that you should be aware of. First of all, they hold the 
> > > values of the selected objects on entry to the embedded interpreter. They 
> > > do not update as you use the LLDB API's to change, for example, the 
> > > currently selected stack frame or thread. 
> > > Moreover, they are only defined and meaningful while in the interactive 
> > > Python interpreter. There is no guarantee on their value in any other 
> > > situation, hence you should not use them when defining Python formatters, 
> > > breakpoint scripts and commands (or any other Python extension point that 
> > > LLDB provides). As a rationale for such behavior, consider that lldb can 
> > > run in a multithreaded environment, and another thread might call the 
> > > "script" command, changing the value out from under you."
> > > 
> > > As part of a formatter, you get passed an SBValue. One of the things you 
> > > can ask of an SBValue is the process it came from, thusly:
> > > 
> > > value.GetProcess()
> > > 
> > > That's the SBProcess object you want to use
> > > 
> > >>  
> > >> Thanks much
> > >> 
> > >>  
> > >>  
> > >>  
> > >> ___
> > >> 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
> > 
> ___
> lldb-dev

Re: [lldb-dev] lldb type summary provider - SBProcess is invalid

2016-09-15 Thread Greg Clayton via lldb-dev 
When using the "script" command, lldb.process/thread/frame are always setup so 
you can use them _in_your_text_, but you probably shouldn't rely on them being 
setup inside your function. You should pass the process to it:

(lldb) script myfile.func(lldb.process, args)

Then you can use "myfile.func" from any other function, including one that 
comes from a command, breakpoint python function, etc and the process will 
always be specified. If you wan't to run a python function as a new LLDB 
command, install a new command line command:


http://lldb.llvm.org/python-reference.html

See the section named: CREATE A NEW LLDB COMMAND USING A PYTHON FUNCTION

Greg

> On Sep 14, 2016, at 10:24 PM, Lei Kong  wrote:
> 
> Does the following qualify as "interactive usage"?  It seems using "process" 
> works in myfile.func(), or I was just lucky? Thanks.
>  
> (lldb) script myfile.func(args)
>  
> > Subject: Re: [lldb-dev] lldb type summary provider - SBProcess is invalid
> > From: gclay...@apple.com
> > Date: Wed, 14 Sep 2016 09:33:20 -0700
> > CC: egran...@apple.com; lldb-dev@lists.llvm.org
> > To: leik...@msn.com
> > 
> > 
> > > On Sep 13, 2016, at 9:50 PM, Lei Kong via lldb-dev 
> > >  wrote:
> > > 
> > > Thanks!
> > > SBValue.process works!
> > >  
> > > I have another script that I run manually to search process memory for 
> > > certain patterns, not a type summary provider, there is no SBValue passed 
> > > to my script, in such a case, how do I get current process?
> > >  
> > If this is python a command line command you are making, use the variant 
> > that takes an execution context:
> > 
> > def my_command(debugger, command, exe_ctx, result, dict):
> > # Always use the specified execution context to get the target, process
> > # thread and frame. If this command gets run from a breakpoint callback
> > # these will not match the debugger's selected target, the selected 
> > # process in the target, the selected thread in the process and the 
> > # selected frame in the thread.
> > target = exe_ctx.GetTarget()
> > process = exe_ctx.GetProcess()
> > thread = exe_ctx.GetThread()
> > frame = exe_ctx.GetFrame()
> > 
> > 
> > The execution context is explicitly specified for you.
> > 
> > > From: Enrico Granata
> > > Sent: Tuesday, September 13, 2016 10:31 AM
> > > To: Lei Kong
> > > Cc: lldb-dev@lists.llvm.org
> > > Subject: Re: [lldb-dev] lldb type summary provider - SBProcess is invalid
> > >  
> > > 
> > >> On Sep 13, 2016, at 10:02 AM, Lei Kong via lldb-dev 
> > >>  wrote:
> > >> 
> > >> I wrote a lldb type summary provider for wstring with 16bit wchar on 
> > >> Ubuntu 16.04.
> > >> 
> > >> Things work fine if I manually do the following in lldb:
> > >> 
> > >> (lldb) script import mytypes
> > >> (lldb) type summary add -F mytypes.wstring_SummaryProvider 
> > >> "std::__1::wstring"
> > >> 
> > >> I tried to make things easier with auto-loading by adding the following 
> > >> to .lldbinit:
> > >> 
> > >> script import mytypes
> > >> type summary add -F mytypes.wstring_SummaryProvider "std::__1::wstring"
> > >> 
> > >> Then I got a failure of "SBProcess is invalid" when printing a wstring 
> > >> variable.
> > >> 
> > >> My type summary function has the following, which I believe is where the 
> > >> error is encountered:
> > >> 
> > >> content = lldb.process.ReadMemory(bufferAddr, byteCount, error)
> > >> 
> > >> Maybe this is because "process" is not assigned yet when the type 
> > >> summary is added during auto-loading? Or this is a bug in lldb? Does 
> > >> anyone know how to work around this issue?
> > >> 
> > >> 
> > > 
> > > Good hunch :-)
> > > Maybe we should do a better job at documenting this, but 
> > > http://lldb.llvm.org/python-reference.html reads
> > > 
> > > "While extremely convenient, these variables (lldb.process et alia) have 
> > > a couple caveats that you should be aware of. First of all, they hold the 
> > > values of the selected objects on entry to the embedded interpreter. They 
> > > do not update as you use the LLDB API's to change, for example, the 
> > > currently selected stack frame or thread. 
> > > Moreover, they are only defined and meaningful while in the interactive 
> > > Python interpreter. There is no guarantee on their value in any other 
> > > situation, hence you should not use them when defining Python formatters, 
> > > breakpoint scripts and commands (or any other Python extension point that 
> > > LLDB provides). As a rationale for such behavior, consider that lldb can 
> > > run in a multithreaded environment, and another thread might call the 
> > > "script" command, changing the value out from under you."
> > > 
> > > As part of a formatter, you get passed an SBValue. One of the things you 
> > > can ask of an SBValue is the process it came from, thusly:
> > > 
> > > value.GetProcess()
> > > 
> > > That's the SBProcess object you want to use
> > > 
> > >>  
> > >> Thanks much
> > >> 
> > >>  
> > >>  
> > >>  
> > >> ___