Re: [lldb-dev] [Release-testers] [3.8 Release] RC2 has been tagged

[Dimitry Andric via lldb-dev]

On 02 Feb 2016, at 22:15, Hans Wennborg via Release-testers 
 wrote:
> 
> Release Candidate 2 has just been tagged [1]. Please build, test, and
> upload to the sftp.
> 
> I know there are still outstanding issues from RC1, but there have
> been a lot of merges going into the branch and I think it's time for
> another round of RC testing.
> 
> This RC comes a little behind schedule, sorry about that, but I'm
> still optimistic about hitting the target of releasing towards the end
> of February.

I've had some trouble getting compiler-rt to build on FreeBSD, but after a few 
minor hacks, I managed to make it build and test successfully for i386.  For 
x86_64, however, there is still a problem in the tsan tests:

/tmp/gotsan.WXO5sLCzBa/gotsan.cc:(.text+0x22d9b): undefined reference to 
`__sanitizer::GetRSS()'
/tmp/gotsan.WXO5sLCzBa/gotsan.cc:(.text+0x22e7b): undefined reference to 
`__sanitizer::GetRSS()'
/tmp/gotsan.WXO5sLCzBa/gotsan.cc:(.text+0x22feb): undefined reference to 
`__sanitizer::GetRSS()'
clang-3.8: error: linker command failed with exit code 1 (use -v to see 
invocation)
projects/compiler-rt/lib/tsan/CMakeFiles/GotsanRuntimeCheck.dir/build.make:50: 
recipe for target 'projects/compiler-rt/lib/tsan/CMakeFiles/GotsanRuntimeCheck' 
failed
gmake[3]: *** [projects/compiler-rt/lib/tsan/CMakeFiles/GotsanRuntimeCheck] 
Error 1

E.g., at some point, GetRSS() got added or split out, but there is no FreeBSD 
variant of this function.  So for now I am probably going to attempt to disable 
tsan only, and continue with the rest of the build.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Sending input to the process being debugged

[Pavel Labath via lldb-dev]

Hi,

I think you will have to provide a bit more context to get help. I.e.,
what is the full sequence of debugger commands you are issuing, and
what is the inferior process doing?

cheers,
pl

On 3 February 2016 at 22:03, John Lindal via lldb-dev
 wrote:
> When I use SBDebugger::SetAsync(true), the process is not stopped at scanf,
> so it does not wait for input.  The process does stop and wait for input
> when SetAsync(false).  Unfortunately, when building a GUI on top of the C++
> API, I have to SetAsync(true).
>
> Is there some way to resolve this?
>
> Thanks,
> John
>
>
> ___
> 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] Debug events in synchronous mode?

[Pavel Labath via lldb-dev]

Hi,

I am not sure what are the "official" rules, but the general idea is
that you need not concern yourself too much with events when you are
in synchronous mode. In synchronous mode, you can be sure that by the
time target.Launch() returns, the process will be stopped (or dead, or
something else, you can check process.GetState() to find that out). No
need to play around with listeners...

cheers,
pl

On 4 February 2016 at 06:41, Jeffrey Tan via lldb-dev
 wrote:
> Hi,
>
> I found that if I am using synchronous mode, some times there are no debug
> events generated during launch. For example, for the code below,
> LLDBListenerThread will receive no debug events.
>
> Is this expected? What is the rule of debug events in synchronous mode?
>
> def main():
> debugger = lldb.SBDebugger.Create()
> debugger.SetAsync(False)
> target = debugger.CreateTargetWithFileAndArch(executable_path,
> lldb.LLDB_ARCH_DEFAULT)
> target.BreakpointCreateByName('main')
>
> listener = lldb.SBListener('Event Listener')
> error = lldb.SBError()
> process = target.Launch (listener,
>  None,  # argv
>  None,  # envp
>  None,  # stdin_path
>  None,  # stdout_path
>  None,  # stderr_path
>  None,  # working directory
>  0, # launch flags
>  False, # Stop at entry
>  error) # error
> print 'Launch result: %s' % str(error)
> event_thread = LLDBListenerThread(debugger)
> event_thread.start()
>
> ___
> 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] Inquiry for performance monitors

[Ravitheja Addepally via lldb-dev]

Hello Pavel,
In the case of expression evaluation approach you mentioned
that:
1. The data could be accessible only when the target is stopped. why is
that ?
2. What sort of noise were you referring to ?



BR,

A Ravi Theja

On Mon, Feb 1, 2016 at 1:05 PM, Tamas Berghammer 
wrote:

> If you want to go with the path to implement it outside LLDB then I would
> suggest to implement it with an out of tree plugin written in C++. You can
> use the SB API the same way as you can from python and additionally it have
> a few advantages:
> * You have a C/C++ API what makes it easy to integrate the functionality
> into an IDE (they just have to link to your shared library)
> * You can generate a Python API if you need one with SWIG the same way we
> do it for the SB API
> * You don't have to worry about making the code both Python 2.7 and Python
> 3.5 compatible
>
> You can see a very simple example for implementing an out of tree C++
> plugin in /examples/plugins/commands
>
> On Mon, Feb 1, 2016 at 10:53 AM Pavel Labath via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Speaking for Android Studio, I think that we *could* use a
>> python-based implementation (hard to say exactly without knowing the
>> details of the implementation), but I believe a different
>> implementation could be *easier* to integrate. Plus, if the solution
>> integrates more closely with lldb, we could surface some of the data
>> in the command-line client as well.
>>
>> pl
>>
>> On 1 February 2016 at 10:30, Ravitheja Addepally
>>  wrote:
>> > And what about the ease of integration into a an IDE, I don't really
>> know if
>> > the python based approach would be usable or not in this context ?
>> >
>> > On Mon, Feb 1, 2016 at 11:17 AM, Pavel Labath 
>> wrote:
>> >>
>> >> It feels to me that the python based approach could run into a dead
>> >> end fairly quickly: a) you can only access the data when the target is
>> >> stopped; b) the self-tracing means that the evaluation of these
>> >> expressions would introduce noise in the data; c) overhead of all the
>> >> extra packets(?).
>> >>
>> >> So, I would be in favor of a lldb-server based approach. I'm not
>> >> telling you that you shouldn't do that, but I don't think that's an
>> >> approach I would take...
>> >>
>> >> pl
>> >>
>> >>
>> >> On 1 February 2016 at 08:58, Ravitheja Addepally
>> >>  wrote:
>> >> > Ok, that is one option, but one of the aim for this activity is to
>> make
>> >> > the
>> >> > data available for use by the IDE's like Android Studio or XCode or
>> any
>> >> > other that may want to display this information in its environment so
>> >> > keeping that in consideration would the complete python based
>> approach
>> >> > be
>> >> > useful ? or would providing LLDB api's to extract raw perf data from
>> the
>> >> > target be useful ?
>> >> >
>> >> > On Thu, Jan 21, 2016 at 10:00 PM, Greg Clayton 
>> >> > wrote:
>> >> >>
>> >> >> One thing to think about is you can actually just run an expression
>> in
>> >> >> the
>> >> >> program that is being debugged without needing to change anything in
>> >> >> the GDB
>> >> >> remote server. So this can all be done via python commands and would
>> >> >> require
>> >> >> no changes to anything. So you can run an expression to enable the
>> >> >> buffer.
>> >> >> Since LLDB supports multiple line expression that can define their
>> own
>> >> >> local
>> >> >> variables and local types. So the expression could be something
>> like:
>> >> >>
>> >> >> int perf_fd = (int)perf_event_open(...);
>> >> >> struct PerfData
>> >> >> {
>> >> >> void *data;
>> >> >> size_t size;
>> >> >> };
>> >> >> PerfData result = read_perf_data(perf_fd);
>> >> >> result
>> >> >>
>> >> >>
>> >> >> The result is then a structure that you can access from your python
>> >> >> command (it will be a SBValue) and then you can read memory in
>> order to
>> >> >> get
>> >> >> the perf data.
>> >> >>
>> >> >> You can also split things up into multiple calls where you can run
>> >> >> perf_event_open() on its own and return the file descriptor:
>> >> >>
>> >> >> (int)perf_event_open(...)
>> >> >>
>> >> >> This expression will return the file descriptor
>> >> >>
>> >> >> Then you could allocate memory via the SBProcess:
>> >> >>
>> >> >> (void *)malloc(1024);
>> >> >>
>> >> >> The result of this expression will be the buffer that you use...
>> >> >>
>> >> >> Then you can read 1024 bytes at a time into this newly created
>> buffer.
>> >> >>
>> >> >> So a solution that is completely done in python would be very
>> >> >> attractive.
>> >> >>
>> >> >> Greg
>> >> >>
>> >> >>
>> >> >> > On Jan 21, 2016, at 7:04 AM, Ravitheja Addepally
>> >> >> >  wrote:
>> >> >> >
>> >> >> > Hello,
>> >> >> >   Regarding the questions in this thread please find the
>> answers
>> >> >> > ->
>> >> >> >
>> >> >> > How are you going to present this information to the user? (I know
>> >> >> > debugserver can report some performance data... Have you looked
>> into
>> >> >

Re: [lldb-dev] Inquiry for performance monitors

[Pavel Labath via lldb-dev]

On 4 February 2016 at 10:04, Ravitheja Addepally
 wrote:
> Hello Pavel,
> In the case of expression evaluation approach you mentioned
> that:
> 1. The data could be accessible only when the target is stopped. why is that
> ?
If I understand the approach correctly, the idea is the run all perf
calls as expressions in the debugger. Something like
lldb> expr perf_event_open(...)
We need to stop the target to be able to do something like that, as we
need to fiddle with its registers. I don't see any way around that...

> 2. What sort of noise were you referring to ?
Since now all the perf calls will be expressions executed within the
context of the process being traced, they themselves will show up in
the trace. I am sure we could filter that out somehow, but it feels
like an added complication..

Does that make it any clearer?

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

Re: [lldb-dev] Problem running the test suite on Linux.

[Pavel Labath via lldb-dev]

In addition to flaky tests, I think some of these are just decorated
too broadly (e.g. it's marked expectedFailureLinux, but fails only on
i386 with gcc). I occasionally enable tests that I see are passing
consistently, but I am currently more worried about tests failing
unexpectedly than succeeding.

The 30 minutes for running the test seems very long, something must
have gone wrong there. If you do a "ps" after 5 minutes, which
processes do you still see running? What about after 15? What are the
specs of the machine you are running this on? What is the exact
command line you launching the tests with?

I wouldn't be too worried about the timeouts, these are the two of our
longest-running tests, so I think they are just getting killed for
running too slow. We need to figure out what is causing the whole
suite to run so slowly. (Unless you see them constantly timing out at
the exact same test, in which case it could be interesting.)

cheers,
pl


On 4 February 2016 at 04:11, Todd Fiala via lldb-dev
 wrote:
>>  I don't recall exactly what it was off the top of my head, but I wonder
>> if Zachary needs that?
>
> That is the lldb_enable_attach() call that I make in the beginning of the
> inferior test driver, defined in
> packages/Python/lldbsuite/test/make/test_common.h.  This is already called,
> so shouldn't be the issue.
>
> On Wed, Feb 3, 2016 at 8:07 PM, Todd Fiala  wrote:
>>
>> You also need to pass "hello, world" as a launch arg (in quotes).  That is
>> what will make it get echoed back.
>>
>> On Wed, Feb 3, 2016 at 8:05 PM, Todd Fiala  wrote:
>>>
>>> Hey Zachary,
>>>
>>> For the test listed above, it is failing trying to match output from the
>>> inferior process being debugged by lldb-server.  First, it is trying to get
>>> a hello, world string to be printed.  Then, it is expecting the process to
>>> exit without failure.
>>>
>>> If you go in that directory and make/run the a.out program, it should
>>> print hello world and exit with an exit value of 0.  You may find that it
>>> doesn't print, perhaps?  Or maybe your terminal is set differently, so that
>>> the text isn't matching as expected?  (I would expect to have heard others
>>> with this issue).
>>>
>>> Pavel just added some gdb remote logging that is easier to access than
>>> the way I had it rigged up before.  If you end up getting stuck, if you get
>>> the output log from either the lldb-server side, that would probably help
>>> figure out what's getting stuck.  But I wouldn't bother with that if you can
>>> rule out that something with the a.out is going wrong first.
>>>
>>> -Todd
>>>
>>> On Wed, Feb 3, 2016 at 3:16 PM, Siva Chandra 
>>> wrote:

 Yes, there is something like that but I am unable to recollect.
 However, I do not think Zach's problem is that. He is able to get all
 but 2 of the tests passing.

 Zach, is it possible for you to run with clang-3.5?

 On Wed, Feb 3, 2016 at 3:05 PM, Todd Fiala  wrote:
 > (Security around ptrace).
 >
 > On Wed, Feb 3, 2016 at 3:04 PM, Todd Fiala 
 > wrote:
 >>
 >> Hmm I wonder if your lldb-server is able to attach to processes?
 >> Siva, we
 >> used to have some kind of kernel flag or something that would allow
 >> attaching to a process that was launched by something else.  I don't
 >> recall
 >> exactly what it was off the top of my head, but I wonder if Zachary
 >> needs
 >> that?
 >>
 >> -Todd
 >>
 >> On Wed, Feb 3, 2016 at 3:02 PM, Zachary Turner via lldb-dev
 >>  wrote:
 >>>
 >>> In my logs I'm seeing this:
 >>>
 >>> UNSUPPORTED: LLDB
 >>>
 >>> (/usr/local/google_ssd/src/llvm/build/ninja_release/bin/clang-3.9-x86_64)
 >>>  ::
 >>> test_inferior_print_exit_debugserver_dwo
 >>> (TestLldbGdbServer.LldbGdbServerTestCase) (debugserver tests)
 >>>   File
 >>>
 >>> "/usr/local/google/home/zturner/ssd/src/llvm/tools/lldb/test/dotest.py",
 >>> line 7, in 
 >>> lldbsuite.test.run_suite()
 >>>   File
 >>>
 >>> "/usr/local/google_ssd/src/llvm/tools/lldb/packages/Python/lldbsuite/test/dotest.py",
 >>> line 1089, in run_suite
 >>> resultclass=test_result.LLDBTestResult).run(configuration.suite)
 >>>   File
 >>>
 >>> "/usr/local/google_ssd/src/llvm/tools/lldb/third_party/Python/module/unittest2/unittest2/runner.py",
 >>> line 162, in run
 >>> test(result)
 >>>   File
 >>>
 >>> "/usr/local/google_ssd/src/llvm/tools/lldb/third_party/Python/module/unittest2/unittest2/suite.py",
 >>> line 65, in __call__
 >>> return self.run(*args, **kwds)
 >>>   File
 >>>
 >>> "/usr/local/google_ssd/src/llvm/tools/lldb/third_party/Python/module/unittest2/unittest2/suite.py",
 >>> line 85, in run
 >>> self._wrapped_run(result)
 >>>   File
 >>>
 >>> "/usr/local/google_ssd/src/llvm/tools/lldb/third_party/Python/module/unittest2/unittest2/suite.py",
 >>> l

Re: [lldb-dev] Inquiry for performance monitors

[Ravitheja Addepally via lldb-dev]

Yes, thanx for the clarification.

On Thu, Feb 4, 2016 at 11:24 AM, Pavel Labath  wrote:

> On 4 February 2016 at 10:04, Ravitheja Addepally
>  wrote:
> > Hello Pavel,
> > In the case of expression evaluation approach you
> mentioned
> > that:
> > 1. The data could be accessible only when the target is stopped. why is
> that
> > ?
> If I understand the approach correctly, the idea is the run all perf
> calls as expressions in the debugger. Something like
> lldb> expr perf_event_open(...)
> We need to stop the target to be able to do something like that, as we
> need to fiddle with its registers. I don't see any way around that...
>
> > 2. What sort of noise were you referring to ?
> Since now all the perf calls will be expressions executed within the
> context of the process being traced, they themselves will show up in
> the trace. I am sure we could filter that out somehow, but it feels
> like an added complication..
>
> Does that make it any clearer?
>
> pl
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Inquiry for performance monitors

[Abhishek Aggarwal via lldb-dev]

Hello Pavel

As per my understanding, instead of doing it by expression evaluation
if the code (to enable pt and gathering the raw traces) is written on
lldb-server side, then also lldb-server will have to wait for the
inferior to stop in order to encapsulate all the traces in packets and
send them to client for analysis.

Is it possible that client can request the lldb-server to send it a
part of the raw traces while the inferior is still running?

- Abhishek

On Thu, Feb 4, 2016 at 1:32 PM, Ravitheja Addepally via lldb-dev
 wrote:
> Yes, thanx for the clarification.
>
> On Thu, Feb 4, 2016 at 11:24 AM, Pavel Labath  wrote:
>>
>> On 4 February 2016 at 10:04, Ravitheja Addepally
>>  wrote:
>> > Hello Pavel,
>> > In the case of expression evaluation approach you
>> > mentioned
>> > that:
>> > 1. The data could be accessible only when the target is stopped. why is
>> > that
>> > ?
>> If I understand the approach correctly, the idea is the run all perf
>> calls as expressions in the debugger. Something like
>> lldb> expr perf_event_open(...)
>> We need to stop the target to be able to do something like that, as we
>> need to fiddle with its registers. I don't see any way around that...
>>
>> > 2. What sort of noise were you referring to ?
>> Since now all the perf calls will be expressions executed within the
>> context of the process being traced, they themselves will show up in
>> the trace. I am sure we could filter that out somehow, but it feels
>> like an added complication..
>>
>> Does that make it any clearer?
>>
>> pl
>
>
>
> ___
> 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] Inquiry for performance monitors

[Pavel Labath via lldb-dev]

On 4 February 2016 at 12:49, Abhishek Aggarwal  wrote:
> Hello Pavel
>
> As per my understanding, instead of doing it by expression evaluation
> if the code (to enable pt and gathering the raw traces) is written on
> lldb-server side, then also lldb-server will have to wait for the
> inferior to stop in order to encapsulate all the traces in packets and
> send them to client for analysis.
>
> Is it possible that client can request the lldb-server to send it a
> part of the raw traces while the inferior is still running?
>

Hi,

This is certainly possible. The server already sends us the stdout
from the inferior this way. There is even some support for gathering
"profile data" in the client (see
GDBRemoteCommunicationClient.cpp:1286), presumably gathering data from
debugserver, as lldb-server does not send such packets. If needed, we
can send the same packets from lldb-server. Or, if these are not
suitable, we can add another kind of packets -- the protocol through
which they communicate is fully under our control.

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

[lldb-dev] FOSDEM slides online

[Renato Golin via lldb-dev]

Hi folks,

FOSDEM was a great success, with the room packed most of the time and
some great talks.

The slides were uploaded to the web page
(http://llvm.org/devmtg/2016-01/) but the videos unfortunately
couldn't be used (they had no audio). Due to the voluntary nature of
FOSDEM, these things can and do happen, so if you want to know more
about a particular presentation, I recommend you contact the original
author, hopefully copying the list, so that further discussions can
progress in the open.

I'd like to thank Sylvestre, Arnaud, Kristof and Tobias for helping
with the organization, and all the presenters for their high quality
talks, and see you all again next year!

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

Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported toolchain

[Pavel Labath via lldb-dev]

Hi all.

we (android lldb team) are starting to transition to VS2015 as well.
For now, the plan is to stick to python 2.7, but if we encounter
problems there, the backup plan is to go to python 3 as well. Until
then (I estimate that will take 1--2 weeks) our buildbot
 will
continue building 2.7+2013 and we will be making sure it works, so
please don't check in any VS2013 incompatible code (yet).

Ted: If you can't switch to the 3+2015 combination (which I *do*
recommend you try), maybe you can go half-way and switch to 2.7+2015
(I can show you how to build python 2.7 with VS2015). If you stick
with 2.7+2013 combo, it will soon be up to you to chase anyone who
adds 2013-breaking changes...

pl


On 2 February 2016 at 23:42, Ted Woodward via lldb-dev
 wrote:
> No, it turned red Friday night/Saturday morning.
>
>
>
> Last good build:
>
> http://lab.llvm.org:8011/builders/lldb-x86-win7-msvc/builds/15167
>
>
>
> First bad build:
>
> http://lab.llvm.org:8011/builders/lldb-x86-win7-msvc/builds/15168
>
>
>
> It went red because of the change to VS2015/Python 3.5.
>
>
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
>
> From: Zachary Turner [mailto:ztur...@google.com]
> Sent: Tuesday, February 02, 2016 5:28 PM
>
>
> To: Ted Woodward; LLDB
> Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported
> toolchain
>
>
>
> BTW, I expect that your buildbot has been experiencing the problems with the
> x86 / x64 toolchain for quite some time, because it's not really relevant to
> how much memory your machine has, but just that it was using an x86
> toolchain at all.  Has it been red for a long time?
>
>
>
> On Tue, Feb 2, 2016 at 1:48 PM Zachary Turner  wrote:
>
> You may have to make some changes to the zorg scripts to keep that working.
> I didn't realize there were any other bots building LLDB, so I made some
> changes that will default everything to VS2015 and Py3.
>
>
>
> BTW, is your builder doing a debug build or a release build?  When doing a
> debug build clang now requires more memory than can fit in a 4GB address
> space to link, so using an x86 toolchain won't work anymore.  I forced a
> change to use the amd64_x86 toolchain, but this won't work unless the
> version of python used by buildbot is a 64-bit Python distro (because
> Python.exe is what ultimately calls vcvarsall and cmake and it inherits the
> environment of the parent).
>
>
>
> So I think you will need to do all this as well.
>
>
>
> On Tue, Feb 2, 2016 at 1:44 PM Ted Woodward 
> wrote:
>
> Then maybe we should keep it 2013/py2.7, until llvm requires 2015.
>
>
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
>
> From: Zachary Turner [mailto:ztur...@google.com]
> Sent: Tuesday, February 02, 2016 3:43 PM
>
>
> To: Ted Woodward; LLDB
> Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported
> toolchain
>
>
>
> It's Server 2008 R2 technically, which is the server version of Win 7 (same
> API set, same OS features, etc).  So yea, I'm pretty confident that test
> coverage is going to be 100% the same across both.  It's just a matter of if
> you want to have something that you maintain / have control over, or if you
> want to test something in a different way than what we're testing.
>
>
>
> On Tue, Feb 2, 2016 at 1:29 PM Ted Woodward 
> wrote:
>
> Yours is Win Server 2008; ours is Win 7. I don’t know if that matters.
>
>
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
>
> From: Zachary Turner [mailto:ztur...@google.com]
> Sent: Tuesday, February 02, 2016 2:48 PM
> To: Ted Woodward; LLDB
>
>
> Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported
> toolchain
>
>
>
> If I remember correctly your bot isn't actually doing anything differently
> than my bot [http://lab.llvm.org:8011/builders/lldb-x86-windows-msvc2015].
> If you want you could just remove your bot.  If you want to keep it, then
> yea getting it on VS2015 and Python 3 would be the best idea.
>
>
>
> On Tue, Feb 2, 2016 at 12:20 PM Ted Woodward via lldb-dev
>  wrote:
>
> It looks like our bot, http://lab.llvm.org:8011/builders/lldb-x86-win7-msvc
> , has tried to update to Python 3.5 and MSVC 2015, but it can’t find python
> or VC. I’ll talk to our buildmiester about it.
>
>
>
> Should we run this guy with 2013/py2.7 or 2015/py3.5?
>
>
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
>
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Zachary
> Turner via lldb-dev
> Sent: Tuesday, February 02, 2016 1:

Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported toolchain

[Zachary Turner via lldb-dev]

Out of curiosity, did you guys get Python 2.7 building with VS2015?  How
did you solve the compiler error?  (I had a few ideas myself for how to fix
it, but I wasn't sure of the implications)

On Thu, Feb 4, 2016 at 8:01 AM Pavel Labath  wrote:

> Hi all.
>
> we (android lldb team) are starting to transition to VS2015 as well.
> For now, the plan is to stick to python 2.7, but if we encounter
> problems there, the backup plan is to go to python 3 as well. Until
> then (I estimate that will take 1--2 weeks) our buildbot
>  will
> continue building 2.7+2013 and we will be making sure it works, so
> please don't check in any VS2013 incompatible code (yet).
>
> Ted: If you can't switch to the 3+2015 combination (which I *do*
> recommend you try), maybe you can go half-way and switch to 2.7+2015
> (I can show you how to build python 2.7 with VS2015). If you stick
> with 2.7+2013 combo, it will soon be up to you to chase anyone who
> adds 2013-breaking changes...
>
> pl
>
>
> On 2 February 2016 at 23:42, Ted Woodward via lldb-dev
>  wrote:
> > No, it turned red Friday night/Saturday morning.
> >
> >
> >
> > Last good build:
> >
> > http://lab.llvm.org:8011/builders/lldb-x86-win7-msvc/builds/15167
> >
> >
> >
> > First bad build:
> >
> > http://lab.llvm.org:8011/builders/lldb-x86-win7-msvc/builds/15168
> >
> >
> >
> > It went red because of the change to VS2015/Python 3.5.
> >
> >
> >
> > --
> >
> > Qualcomm Innovation Center, Inc.
> >
> > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> > Linux Foundation Collaborative Project
> >
> >
> >
> > From: Zachary Turner [mailto:ztur...@google.com]
> > Sent: Tuesday, February 02, 2016 5:28 PM
> >
> >
> > To: Ted Woodward; LLDB
> > Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an
> unsupported
> > toolchain
> >
> >
> >
> > BTW, I expect that your buildbot has been experiencing the problems with
> the
> > x86 / x64 toolchain for quite some time, because it's not really
> relevant to
> > how much memory your machine has, but just that it was using an x86
> > toolchain at all.  Has it been red for a long time?
> >
> >
> >
> > On Tue, Feb 2, 2016 at 1:48 PM Zachary Turner 
> wrote:
> >
> > You may have to make some changes to the zorg scripts to keep that
> working.
> > I didn't realize there were any other bots building LLDB, so I made some
> > changes that will default everything to VS2015 and Py3.
> >
> >
> >
> > BTW, is your builder doing a debug build or a release build?  When doing
> a
> > debug build clang now requires more memory than can fit in a 4GB address
> > space to link, so using an x86 toolchain won't work anymore.  I forced a
> > change to use the amd64_x86 toolchain, but this won't work unless the
> > version of python used by buildbot is a 64-bit Python distro (because
> > Python.exe is what ultimately calls vcvarsall and cmake and it inherits
> the
> > environment of the parent).
> >
> >
> >
> > So I think you will need to do all this as well.
> >
> >
> >
> > On Tue, Feb 2, 2016 at 1:44 PM Ted Woodward  >
> > wrote:
> >
> > Then maybe we should keep it 2013/py2.7, until llvm requires 2015.
> >
> >
> >
> > --
> >
> > Qualcomm Innovation Center, Inc.
> >
> > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> > Linux Foundation Collaborative Project
> >
> >
> >
> > From: Zachary Turner [mailto:ztur...@google.com]
> > Sent: Tuesday, February 02, 2016 3:43 PM
> >
> >
> > To: Ted Woodward; LLDB
> > Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an
> unsupported
> > toolchain
> >
> >
> >
> > It's Server 2008 R2 technically, which is the server version of Win 7
> (same
> > API set, same OS features, etc).  So yea, I'm pretty confident that test
> > coverage is going to be 100% the same across both.  It's just a matter
> of if
> > you want to have something that you maintain / have control over, or if
> you
> > want to test something in a different way than what we're testing.
> >
> >
> >
> > On Tue, Feb 2, 2016 at 1:29 PM Ted Woodward  >
> > wrote:
> >
> > Yours is Win Server 2008; ours is Win 7. I don’t know if that matters.
> >
> >
> >
> > --
> >
> > Qualcomm Innovation Center, Inc.
> >
> > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> > Linux Foundation Collaborative Project
> >
> >
> >
> > From: Zachary Turner [mailto:ztur...@google.com]
> > Sent: Tuesday, February 02, 2016 2:48 PM
> > To: Ted Woodward; LLDB
> >
> >
> > Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an
> unsupported
> > toolchain
> >
> >
> >
> > If I remember correctly your bot isn't actually doing anything
> differently
> > than my bot [http://lab.llvm.org:8011/builders/lldb-x86-windows-msvc2015
> ].
> > If you want you could just remove your bot.  If you want to keep it, then
> > yea getting it on VS2015 and Python 3 would be the best idea.
> >
> >
> >
> > On Tue, Feb 2, 2016 at 12:20 PM Ted Woodward via lldb-dev
>

Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported toolchain

[Pavel Labath via lldb-dev]

The patch is in the attachment.

The timezone part seems pretty non-controversial. The _PyVerify_fd
thing seems more scary, but I basically copied that part out of
python3, so I assume they know what they are doing. With this I can
compile and run the python and it appears to be working. The real test
will be when I try to run the lldb test suite with it, but I didn't
set that up yet.

pl

On 4 February 2016 at 16:06, Zachary Turner  wrote:
> Out of curiosity, did you guys get Python 2.7 building with VS2015?  How did
> you solve the compiler error?  (I had a few ideas myself for how to fix it,
> but I wasn't sure of the implications)
>
> On Thu, Feb 4, 2016 at 8:01 AM Pavel Labath  wrote:
>>
>> Hi all.
>>
>> we (android lldb team) are starting to transition to VS2015 as well.
>> For now, the plan is to stick to python 2.7, but if we encounter
>> problems there, the backup plan is to go to python 3 as well. Until
>> then (I estimate that will take 1--2 weeks) our buildbot
>>  will
>> continue building 2.7+2013 and we will be making sure it works, so
>> please don't check in any VS2013 incompatible code (yet).
>>
>> Ted: If you can't switch to the 3+2015 combination (which I *do*
>> recommend you try), maybe you can go half-way and switch to 2.7+2015
>> (I can show you how to build python 2.7 with VS2015). If you stick
>> with 2.7+2013 combo, it will soon be up to you to chase anyone who
>> adds 2013-breaking changes...
>>
>> pl
>>
>>
>> On 2 February 2016 at 23:42, Ted Woodward via lldb-dev
>>  wrote:
>> > No, it turned red Friday night/Saturday morning.
>> >
>> >
>> >
>> > Last good build:
>> >
>> > http://lab.llvm.org:8011/builders/lldb-x86-win7-msvc/builds/15167
>> >
>> >
>> >
>> > First bad build:
>> >
>> > http://lab.llvm.org:8011/builders/lldb-x86-win7-msvc/builds/15168
>> >
>> >
>> >
>> > It went red because of the change to VS2015/Python 3.5.
>> >
>> >
>> >
>> > --
>> >
>> > Qualcomm Innovation Center, Inc.
>> >
>> > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
>> > Linux Foundation Collaborative Project
>> >
>> >
>> >
>> > From: Zachary Turner [mailto:ztur...@google.com]
>> > Sent: Tuesday, February 02, 2016 5:28 PM
>> >
>> >
>> > To: Ted Woodward; LLDB
>> > Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an
>> > unsupported
>> > toolchain
>> >
>> >
>> >
>> > BTW, I expect that your buildbot has been experiencing the problems with
>> > the
>> > x86 / x64 toolchain for quite some time, because it's not really
>> > relevant to
>> > how much memory your machine has, but just that it was using an x86
>> > toolchain at all.  Has it been red for a long time?
>> >
>> >
>> >
>> > On Tue, Feb 2, 2016 at 1:48 PM Zachary Turner 
>> > wrote:
>> >
>> > You may have to make some changes to the zorg scripts to keep that
>> > working.
>> > I didn't realize there were any other bots building LLDB, so I made some
>> > changes that will default everything to VS2015 and Py3.
>> >
>> >
>> >
>> > BTW, is your builder doing a debug build or a release build?  When doing
>> > a
>> > debug build clang now requires more memory than can fit in a 4GB address
>> > space to link, so using an x86 toolchain won't work anymore.  I forced a
>> > change to use the amd64_x86 toolchain, but this won't work unless the
>> > version of python used by buildbot is a 64-bit Python distro (because
>> > Python.exe is what ultimately calls vcvarsall and cmake and it inherits
>> > the
>> > environment of the parent).
>> >
>> >
>> >
>> > So I think you will need to do all this as well.
>> >
>> >
>> >
>> > On Tue, Feb 2, 2016 at 1:44 PM Ted Woodward
>> > 
>> > wrote:
>> >
>> > Then maybe we should keep it 2013/py2.7, until llvm requires 2015.
>> >
>> >
>> >
>> > --
>> >
>> > Qualcomm Innovation Center, Inc.
>> >
>> > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
>> > Linux Foundation Collaborative Project
>> >
>> >
>> >
>> > From: Zachary Turner [mailto:ztur...@google.com]
>> > Sent: Tuesday, February 02, 2016 3:43 PM
>> >
>> >
>> > To: Ted Woodward; LLDB
>> > Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an
>> > unsupported
>> > toolchain
>> >
>> >
>> >
>> > It's Server 2008 R2 technically, which is the server version of Win 7
>> > (same
>> > API set, same OS features, etc).  So yea, I'm pretty confident that test
>> > coverage is going to be 100% the same across both.  It's just a matter
>> > of if
>> > you want to have something that you maintain / have control over, or if
>> > you
>> > want to test something in a different way than what we're testing.
>> >
>> >
>> >
>> > On Tue, Feb 2, 2016 at 1:29 PM Ted Woodward
>> > 
>> > wrote:
>> >
>> > Yours is Win Server 2008; ours is Win 7. I don’t know if that matters.
>> >
>> >
>> >
>> > --
>> >
>> > Qualcomm Innovation Center, Inc.
>> >
>> > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
>> > Linux Foundation Collaborative Project
>> >

Re: [lldb-dev] [Release-testers] [3.8 Release] RC2 has been tagged

[Dimitry Andric via lldb-dev]

On 04 Feb 2016, at 09:09, Dimitry Andric via Release-testers 
 wrote:
> 
> On 02 Feb 2016, at 22:15, Hans Wennborg via Release-testers 
>  wrote:
>> 
>> Release Candidate 2 has just been tagged [1]. Please build, test, and
>> upload to the sftp.
>> 
>> I know there are still outstanding issues from RC1, but there have
>> been a lot of merges going into the branch and I think it's time for
>> another round of RC testing.
>> 
>> This RC comes a little behind schedule, sorry about that, but I'm
>> still optimistic about hitting the target of releasing towards the end
>> of February.
> 
> I've had some trouble getting compiler-rt to build on FreeBSD, but after a 
> few minor hacks, I managed to make it build and test successfully for i386.  
> For x86_64, however, there is still a problem in the tsan tests:
> 
> /tmp/gotsan.WXO5sLCzBa/gotsan.cc:(.text+0x22d9b): undefined reference to 
> `__sanitizer::GetRSS()'
> /tmp/gotsan.WXO5sLCzBa/gotsan.cc:(.text+0x22e7b): undefined reference to 
> `__sanitizer::GetRSS()'
> /tmp/gotsan.WXO5sLCzBa/gotsan.cc:(.text+0x22feb): undefined reference to 
> `__sanitizer::GetRSS()'
> clang-3.8: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> projects/compiler-rt/lib/tsan/CMakeFiles/GotsanRuntimeCheck.dir/build.make:50:
>  recipe for target 
> 'projects/compiler-rt/lib/tsan/CMakeFiles/GotsanRuntimeCheck' failed
> gmake[3]: *** [projects/compiler-rt/lib/tsan/CMakeFiles/GotsanRuntimeCheck] 
> Error 1
> 
> E.g., at some point, GetRSS() got added or split out, but there is no FreeBSD 
> variant of this function.  So for now I am probably going to attempt to 
> disable tsan only, and continue with the rest of the build.

After disabling tsan for x86_64, the builds finally went OK, and all tests 
succeeded.  So these tarballs now also have compiler-rt in them, though 
unfortunately still no libc++:

SHA256 (clang+llvm-3.8.0-rc2-amd64-unknown-freebsd10.tar.xz) = 
d6a709e38aa274cc58130b755ef3c1c1fc34b36cc2bfcb6bfa4118b23b0c834e
SHA256 (clang+llvm-3.8.0-rc2-i386-unknown-freebsd10.tar.xz) = 
840b3a391ef3dfec20ed5464230caad91f6431e655d0c6ae06cbabdd7ed12a73

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Debug events in synchronous mode?

[Jim Ingham via lldb-dev]

In synchronous mode, you should never see events.  The part of lldb that is 
making the command synchronous is using those events to make the command wait 
till the action it initiated completes before it returns.  If it is letting 
process control events leak out, then that is a bug.

If you are running in async mode (and haven't set stop-at-entry in the launch 
options), then you won't see an event till the process stops for some other 
reason (e.g. hitting a breakpoint.)  If launch returns with no error, then your 
process got launched, and you should just wait for it to stop.

Jim

> On Feb 4, 2016, at 1:21 AM, Pavel Labath via lldb-dev 
>  wrote:
> 
> Hi,
> 
> I am not sure what are the "official" rules, but the general idea is
> that you need not concern yourself too much with events when you are
> in synchronous mode. In synchronous mode, you can be sure that by the
> time target.Launch() returns, the process will be stopped (or dead, or
> something else, you can check process.GetState() to find that out). No
> need to play around with listeners...
> 
> cheers,
> pl
> 
> On 4 February 2016 at 06:41, Jeffrey Tan via lldb-dev
>  wrote:
>> Hi,
>> 
>> I found that if I am using synchronous mode, some times there are no debug
>> events generated during launch. For example, for the code below,
>> LLDBListenerThread will receive no debug events.
>> 
>> Is this expected? What is the rule of debug events in synchronous mode?
>> 
>> def main():
>>debugger = lldb.SBDebugger.Create()
>>debugger.SetAsync(False)
>>target = debugger.CreateTargetWithFileAndArch(executable_path,
>> lldb.LLDB_ARCH_DEFAULT)
>>target.BreakpointCreateByName('main')
>> 
>>listener = lldb.SBListener('Event Listener')
>>error = lldb.SBError()
>>process = target.Launch (listener,
>> None,  # argv
>> None,  # envp
>> None,  # stdin_path
>> None,  # stdout_path
>> None,  # stderr_path
>> None,  # working directory
>> 0, # launch flags
>> False, # Stop at entry
>> error) # error
>>print 'Launch result: %s' % str(error)
>>event_thread = LLDBListenerThread(debugger)
>>event_thread.start()
>> 
>> ___
>> 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] MSVC 2013 w/ Python 2.7 is moving to an unsupported toolchain

[Ted Woodward via lldb-dev]

We can change to 3+2015; if you guys don't think 2+2013 is useful, we'll do 
that.

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

-Original Message-
From: Pavel Labath [mailto:lab...@google.com] 
Sent: Thursday, February 04, 2016 10:01 AM
To: Ted Woodward
Cc: Zachary Turner; LLDB
Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported 
toolchain

Hi all.

we (android lldb team) are starting to transition to VS2015 as well.
For now, the plan is to stick to python 2.7, but if we encounter problems 
there, the backup plan is to go to python 3 as well. Until then (I estimate 
that will take 1--2 weeks) our buildbot 
 will continue 
building 2.7+2013 and we will be making sure it works, so please don't check in 
any VS2013 incompatible code (yet).

Ted: If you can't switch to the 3+2015 combination (which I *do* recommend you 
try), maybe you can go half-way and switch to 2.7+2015 (I can show you how to 
build python 2.7 with VS2015). If you stick with 2.7+2013 combo, it will soon 
be up to you to chase anyone who adds 2013-breaking changes...

pl


On 2 February 2016 at 23:42, Ted Woodward via lldb-dev 
 wrote:
> No, it turned red Friday night/Saturday morning.
>
>
>
> Last good build:
>
> http://lab.llvm.org:8011/builders/lldb-x86-win7-msvc/builds/15167
>
>
>
> First bad build:
>
> http://lab.llvm.org:8011/builders/lldb-x86-win7-msvc/builds/15168
>
>
>
> It went red because of the change to VS2015/Python 3.5.
>
>
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
> a Linux Foundation Collaborative Project
>
>
>
> From: Zachary Turner [mailto:ztur...@google.com]
> Sent: Tuesday, February 02, 2016 5:28 PM
>
>
> To: Ted Woodward; LLDB
> Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an 
> unsupported toolchain
>
>
>
> BTW, I expect that your buildbot has been experiencing the problems 
> with the
> x86 / x64 toolchain for quite some time, because it's not really 
> relevant to how much memory your machine has, but just that it was 
> using an x86 toolchain at all.  Has it been red for a long time?
>
>
>
> On Tue, Feb 2, 2016 at 1:48 PM Zachary Turner  wrote:
>
> You may have to make some changes to the zorg scripts to keep that working.
> I didn't realize there were any other bots building LLDB, so I made 
> some changes that will default everything to VS2015 and Py3.
>
>
>
> BTW, is your builder doing a debug build or a release build?  When 
> doing a debug build clang now requires more memory than can fit in a 
> 4GB address space to link, so using an x86 toolchain won't work 
> anymore.  I forced a change to use the amd64_x86 toolchain, but this 
> won't work unless the version of python used by buildbot is a 64-bit 
> Python distro (because Python.exe is what ultimately calls vcvarsall 
> and cmake and it inherits the environment of the parent).
>
>
>
> So I think you will need to do all this as well.
>
>
>
> On Tue, Feb 2, 2016 at 1:44 PM Ted Woodward 
> 
> wrote:
>
> Then maybe we should keep it 2013/py2.7, until llvm requires 2015.
>
>
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
> a Linux Foundation Collaborative Project
>
>
>
> From: Zachary Turner [mailto:ztur...@google.com]
> Sent: Tuesday, February 02, 2016 3:43 PM
>
>
> To: Ted Woodward; LLDB
> Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an 
> unsupported toolchain
>
>
>
> It's Server 2008 R2 technically, which is the server version of Win 7 
> (same API set, same OS features, etc).  So yea, I'm pretty confident 
> that test coverage is going to be 100% the same across both.  It's 
> just a matter of if you want to have something that you maintain / 
> have control over, or if you want to test something in a different way than 
> what we're testing.
>
>
>
> On Tue, Feb 2, 2016 at 1:29 PM Ted Woodward 
> 
> wrote:
>
> Yours is Win Server 2008; ours is Win 7. I don’t know if that matters.
>
>
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
> a Linux Foundation Collaborative Project
>
>
>
> From: Zachary Turner [mailto:ztur...@google.com]
> Sent: Tuesday, February 02, 2016 2:48 PM
> To: Ted Woodward; LLDB
>
>
> Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an 
> unsupported toolchain
>
>
>
> If I remember correctly your bot isn't actually doing anything 
> differently than my bot 
> [http://lab.llvm.org:8011/builders/lldb-x86-windows-msvc2015].
> If you want you could just remove your bot.  If you want to keep it, 
> then yea getting it on VS2015 and Python 3 would be the best idea.
>
>
>
> On Tue, Feb 2, 2016 at 12:20 PM Ted Woodward via lldb-dev 
>  wrote:
>
> It looks like our bot, 
> http://lab.llvm.org:80

Re: [lldb-dev] [cfe-dev] [3.8 Release] RC2 has been tagged

[Brian Cain via lldb-dev]

Tested RC2 w/SLES11.3, x86_64.  No regressions.

81c1ea3fafee883fbbd396779d1e62714304eff6
 rc2/clang+llvm-3.8.0-rc2-linux-x86_64-sles11.3.tar.xz


On Tue, Feb 2, 2016 at 3:15 PM, Hans Wennborg via cfe-dev <
cfe-...@lists.llvm.org> wrote:

> Dear testers,
>
> Release Candidate 2 has just been tagged [1]. Please build, test, and
> upload to the sftp.
>
> I know there are still outstanding issues from RC1, but there have
> been a lot of merges going into the branch and I think it's time for
> another round of RC testing.
>
> This RC comes a little behind schedule, sorry about that, but I'm
> still optimistic about hitting the target of releasing towards the end
> of February.
>
> Thanks for all the work you've put into this release so far!
>
> Hans
>
>  [1]
> http://lists.llvm.org/pipermail/llvm-branch-commits/2016-February/009739.html
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>



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

Re: [lldb-dev] Inquiry for performance monitors

[Greg Clayton via lldb-dev]

> On Feb 4, 2016, at 2:24 AM, Pavel Labath via lldb-dev 
>  wrote:
> 
> On 4 February 2016 at 10:04, Ravitheja Addepally
>  wrote:
>> Hello Pavel,
>>In the case of expression evaluation approach you mentioned
>> that:
>> 1. The data could be accessible only when the target is stopped. why is that
>> ?
> If I understand the approach correctly, the idea is the run all perf
> calls as expressions in the debugger. Something like
> lldb> expr perf_event_open(...)
> We need to stop the target to be able to do something like that, as we
> need to fiddle with its registers. I don't see any way around that...
> 
>> 2. What sort of noise were you referring to ?
> Since now all the perf calls will be expressions executed within the
> context of the process being traced, they themselves will show up in
> the trace. I am sure we could filter that out somehow, but it feels
> like an added complication..
> 
> Does that make it any clearer?

So a few questions: people seem worried about running something in the process 
if expression are being used. Are you saying that if the process is on the 
local machine, process 1 can just open up a file descriptor to the trace data 
for process 2? If so, why pass this through lldb-server? I am not a big fan 
making the lldb-server become the conduits for a ton of information. It just 
isn't built for that high volumes of data coming in. I can be done, but that 
doesn't mean it should. If everyone starts passing data like memory usage, CPU 
time, trace info, backtraces and more through asynchronously through 
lldb-server, it will become a very crowded communication channel. 

You don't need python if you want to do this using the lldb API. If your IDE is 
already linking against the LLDB shared library, it can just run the 
expressions using the public LLDB API. This is how view debugging is 
implemented in Xcode. It runs complex expressions that gather all data about a 
view and its subviews and returns all the layers in a blob of data that can be 
serialized by the expression, retrieved by Xcode (memory read from the 
process), and then de-serialized by the IDE into a format that can be used. If 
your IDE can access the trace data for another process, why not just read it 
from the IDE itself? Why get the lldb-server involved? Granted the remote 
debugging parts of this make an argument for including it in the lldb-server. 
But if you go this route you need to make a base implementation for trace data 
that will work for any trace data, have trace data plug-ins that somehow know 
how to interpret the data and provide. 

How do you say "here is a blob of trace data" I just got from some process, go 
find me a plug-in that can parse it. You might have to say "here is a blob of 
data" and it is for the "intel" trace data plug-in. How are we going to know 
which trace data to ask for? Is the packet we send to lldb-server going to 
reply to "qGetTraceData" with something that says the type of data is 
"intel-IEEE-version-123.3.1" and the data is "xxx"? Then we would find a 
plug-in in LLDB for that trace data that can parse it? So you will need to 
think about completely abstracting the whole notion of trace data into some 
sensible API that gets exposed via SBProcess. 

So yes, there are two approaches to take. Let me know which one is the way you 
want to go. But I really want to avoid the GDB remote protocol's async packets 
becoming the conduit for a boat load of information. 

Greg Clayton


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

[lldb-dev] lldb-mi and shared library path

[Ted Woodward via lldb-dev]

I'd expect "-gdb-set solib-search-path" to call "target modules search-paths
add", and it does, but only when the -target-remote command is issued. It
also doesn't handle the multiple path case, :.

 

I think it should:

 

1)  Set the search path immediately when called, if the target is
connected

2)  Set the search path on run/attach

3)  Handle multiple paths

 

Any thoughts on this?

 

Ted

 

--

Qualcomm Innovation Center, Inc.

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

 

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

[lldb-dev] Minidump support in LLDB

[Adrian McCarthy via lldb-dev]

Below is an after-the-fact design doc on the minidump support in LLDB.  We
don't seem to have a documents repository, so I thought I'd post it here on
the mailing list in case anyone wants to know more.  Comments and questions
welcome.

Thanks,
Adrian.

---
Minidump support in LLDB

Adrian McCarthy

amcca...@google.com

This is an “as-built” design document describing how minidump support was
added to LLDB on Windows.

Minidumps are the Windows equivalent of a core file.  The format is
well-documented (unlike core files), so some crash-reporting tools (like
Breakpad) have chosen to use the minidump format not only on Windows, but
also on all other platforms

it supports.  Chromium and other Google projects use Breakpad, so minidump
support in LLDB is important for Google.
Status

Currently, LLDB supports debugging 32-bit minidumps on Windows for binaries
built with DWARF debug information (e.g., with clang-cl).  Tests ensure
that we can see stacks for all threads and inspect local variables and
parameters and that it is possible to inspect any section of process memory
captured in the dump.
Process Plugin for Minidump

A new process plugin was created for minidump support.  It parallels the
Windows process plugin (for debugging live processes on Windows) and the
ELF core process plugin (for postmortem analysis of core files).

The minidump plugin is smaller than the ELF core plugin, largely because
the ELF core plugin contains all of the code for parsing a core file.  The
minidump plugin currently relies on a Windows API and structure definitions
in order to parse it.  The minidump format appears simpler than the core
file format.  Nevertheless, if we decide to parse it directly in LLDB, the
parsing code should probably be in a separate translation unit than the
minidump plugin.

The minidump plugin is also smaller than the Windows process plugin, which
handles debugging of live processes.  Debugging a live process on Windows
involves tracking more state and managing a separate debugger thread for
receiving and dispatching debugging events.

Small parts of the existing ProcessWindows plugin were factored up into a
new base class to be used by both the ProcessWindowsLive and the new
ProcessWindowsMiniDump process plugins.

Small amounts of code were factored out of the Windows-specific Register
and Thread classes so they could also be re-used by the minidump
counterparts.  The minidump versions of these classes are simpler than
their live-debugging counterparts since they are read-only.

Upon opening the minidump, the plugin reads several sections in order to
capture the process ID, the module list, and the exception record.  The
plugin extracts information about the threads that were running when LLDB
calls back into the plugin’s UpdateThreadList.

As a first pass, LLDB supports Minidump only on Windows, because it uses
the Windows-provided API MiniDumpReadDumpStream for accessing the
minidump.  But use of this API is localized to a single location, so it can
easily be swapped out for an independent implementation of this
functionality.
Writing Minidumps

The `process save-core` command was extended for Windows to create a
minidump file.  It currently uses the Windows API MiniDumpWriteDump
.
As with reading, this could be replaced to allow writing a minidump on any
platform.  That would require an option on the `process save-core` command
in order to specify which format was desired when there is a choice (we’re
not like to start offer Unix-style core files on Windows).

Since the minidump format is documented and not particularly complex,
providing another implementation should be straightforward and would allow
for debugging minidumps on MacOS or Linux, even if those minidumps are from
a Windows host.
Testing

There are a small number of basic tests to ensure that LLDB can open a
minidump, find the threads, inspect the stack and local variables, and
write a minidump.

Some of these tests execute against checked-in minidumps that were captured
with Visual Studio and others use LLDB’s ability to write a minidump to
first capture a dump and then to inspect it.  We need tests that check
minidumps from more elaborate (or, at least larger scale) programs.
Future Work

   -

   Test minidump debugging functionality with a substantial application
   like Chromium.
   -

   Read the minidump directly instead of using the Windows API interface.
   This would be the key step in making cross-platform crash dump analysis
   possible.
   -

   Implement the 64-bit register model for Windows crash-dump debugging.
   There is a bit of work here to make sure it works on WoW32.
   -

   Write minidumps on any platform by implementing our own version of
   MiniDumpWriteDump and adding an option to the `process save-core` command
   to select the format.
   - Investiga

Re: [lldb-dev] Debug events in synchronous mode?

[Jeffrey Tan via lldb-dev]

Jim, thanks for the confirmation. It seems to me that there are many
quirks of LLDB API that you have to be aware of before you can
automate it correctly. Are these quirks documented somewhere that I
missed? I have looked at examples/tests folders of LLDB and python API
pages, both do not have enough depths as the discussions here.


> On Feb 4, 2016, at 11:23 AM, Jim Ingham  wrote:
>
> In synchronous mode, you should never see events.  The part of lldb that is 
> making the command synchronous is using those events to make the command wait 
> till the action it initiated completes before it returns.  If it is letting 
> process control events leak out, then that is a bug.
>
> If you are running in async mode (and haven't set stop-at-entry in the launch 
> options), then you won't see an event till the process stops for some other 
> reason (e.g. hitting a breakpoint.)  If launch returns with no error, then 
> your process got launched, and you should just wait for it to stop.
>
> Jim
>
>> On Feb 4, 2016, at 1:21 AM, Pavel Labath via lldb-dev 
>>  wrote:
>>
>> Hi,
>>
>> I am not sure what are the "official" rules, but the general idea is
>> that you need not concern yourself too much with events when you are
>> in synchronous mode. In synchronous mode, you can be sure that by the
>> time target.Launch() returns, the process will be stopped (or dead, or
>> something else, you can check process.GetState() to find that out). No
>> need to play around with listeners...
>>
>> cheers,
>> pl
>>
>> On 4 February 2016 at 06:41, Jeffrey Tan via lldb-dev
>>  wrote:
>>> Hi,
>>>
>>> I found that if I am using synchronous mode, some times there are no debug
>>> events generated during launch. For example, for the code below,
>>> LLDBListenerThread will receive no debug events.
>>>
>>> Is this expected? What is the rule of debug events in synchronous mode?
>>>
>>> def main():
>>>   debugger = lldb.SBDebugger.Create()
>>>   debugger.SetAsync(False)
>>>   target = debugger.CreateTargetWithFileAndArch(executable_path,
>>> lldb.LLDB_ARCH_DEFAULT)
>>>   target.BreakpointCreateByName('main')
>>>
>>>   listener = lldb.SBListener('Event Listener')
>>>   error = lldb.SBError()
>>>   process = target.Launch (listener,
>>>None,  # argv
>>>None,  # envp
>>>None,  # stdin_path
>>>None,  # stdout_path
>>>None,  # stderr_path
>>>None,  # working directory
>>>0, # launch flags
>>>False, # Stop at entry
>>>error) # error
>>>   print 'Launch result: %s' % str(error)
>>>   event_thread = LLDBListenerThread(debugger)
>>>   event_thread.start()
>>>
>>> ___
>>> 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

[lldb-dev] Race condition crashes during launching LLDB

[Jeffrey Tan via lldb-dev]

Hi,

I am revising our lldb automation tests into async mode. However, I found
it randomly crashes depends on timing. And the crash happens mostly while
launching lldb twice in a row. I have narrowed down the code into a simple
repro below. Any assumption I made wrong with the LLDB API here?

The crash stack seems to be not consistently. In the small repro below, the
crash stack is:
Crashed Thread:0  Dispatch queue: com.apple.main-thread

Exception Type:EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:   EXC_I386_GPFLT

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   _lldb.so   0x0001088c7179
EventMatcher::operator()(std::__1::shared_ptr const&)
const + 21
1   _lldb.so   0x0001088c65d2
lldb_private::Listener::FindNextEventInternal(lldb_private::Broadcaster*,
lldb_private::ConstString const*, unsigned int, unsigned int,
std::__1::shared_ptr&, bool) + 176
2   _lldb.so   0x0001088c6952
lldb_private::Listener::WaitForEventsInternal(lldb_private::TimeValue
const*, lldb_private::Broadcaster*, lldb_private::ConstString const*,
unsigned int, unsigned int, std::__1::shared_ptr&) +
134
3   _lldb.so   0x0001088c6ae9
lldb_private::Listener::WaitForEventForBroadcasterWithType(lldb_private::TimeValue
const*, lldb_private::Broadcaster*, unsigned int,
std::__1::shared_ptr&) + 27
4   _lldb.so   0x000108abce6c
lldb_private::Process::WaitForStateChangedEvents(lldb_private::TimeValue
const*, std::__1::shared_ptr&,
lldb_private::Listener*) + 112
5   _lldb.so   0x000108abcc95
lldb_private::Process::WaitForProcessToStop(lldb_private::TimeValue const*,
std::__1::shared_ptr*, bool, lldb_private::Listener*,
lldb_private::Stream*) + 377
6   _lldb.so   0x000108ac516a
lldb_private::Process::HaltForDestroyOrDetach(std::__1::shared_ptr&)
+ 216
7   _lldb.so   0x000108abc8b0
lldb_private::Process::Destroy(bool) + 146
8   _lldb.so   0x000108abc56d
lldb_private::Process::Finalize() + 91
9   _lldb.so   0x0001088b63c4
lldb_private::Debugger::Clear() + 148
10  _lldb.so   0x0001088b61fd
lldb_private::Debugger::Destroy(std::__1::shared_ptr&)
+ 37
11  _lldb.so   0x000106bdb144
lldb::SBDebugger::Destroy(lldb::SBDebugger&) + 116
12  _lldb.so   0x000106c23daf
_wrap_SBDebugger_Destroy(_object*, _object*) + 120
13  org.python.python 0x0001058dd75f PyEval_EvalFrameEx +
12761

while in the real unit test it is crashing at:
Thread 12 Crashed:
0   libsystem_kernel.dylib 0x7fff8635a286 __pthread_kill + 10
1   libsystem_c.dylib 0x7fff919409b3 abort + 129
2   libc++abi.dylib   0x7fff8a94ea21 abort_message + 257
3   libc++abi.dylib   0x7fff8a9769d1
default_terminate_handler() + 267
4   libobjc.A.dylib   0x7fff935e77eb _objc_terminate() + 124
5   libc++abi.dylib   0x7fff8a9740a1 std::__terminate(void
(*)()) + 8
6   libc++abi.dylib   0x7fff8a973b30 __cxa_throw + 121
7   com.apple.LLDB.framework   0x00010b994c6b
std::__1::shared_ptr::shared_ptr(std::__1::weak_ptr
const&, std::__1::enable_if::value,
std::__1::shared_ptr::__nat>::type) + 99
8   com.apple.LLDB.framework   0x00010b8ac762
lldb_private::Process::AppendSTDOUT(char const*, unsigned long) + 86
9   com.apple.LLDB.framework   0x00010b6951d7
lldb_private::Communication::ReadThread(void*) + 287
10  libsystem_pthread.dylib   0x7fff8d92c05a _pthread_body + 131
11  libsystem_pthread.dylib   0x7fff8d92bfd7 _pthread_start + 176


Repro Code

def wait_for_process_stop(process):
while not process.is_stopped:
time.sleep(0.1)

def launch_debugging(debugger, stop_at_entry):
error = lldb.SBError()
listener = lldb.SBListener('Chrome Dev Tools Listener')
target = debugger.GetSelectedTarget()
process = target.Launch (listener,
None,  # argv
None,  # envp
None,  # stdin_path
None,  # stdout_path
None,  # stderr_path
None,  # working directory
0, # launch flags
stop_at_entry,  # Stop at entry
error) # error
print 'Launch result: %s' % str(error)
event_thread = LLDBListenerThread(debugger)
event_thread.start()
return process

def do_test():
debugger = lldb.SBDebugger.Create()
debugger.SetAsync(True)
target = debugger.CreateTargetWithFileAndArch(executable_path,
lldb.LLDB_ARCH_DEFAULT)

process = launch_debugging(debugger, stop_at_entry=True)

wait_for_process_stop(process) # wait for entry breakpoint.
target.Breakpo

Re: [lldb-dev] Race condition crashes during launching LLDB

[Jim Ingham via lldb-dev]

I don't know what:

event_thread = LLDBListenerThread(debugger)

does, but from your little sketch it looks like you are starting up a thread 
listening on this debugger, and so far as I can see you destroy the debugger 
out from under it without ever closing down that thread.  That doesn't seem 
like a good idea.

Jim




> On Feb 4, 2016, at 5:27 PM, Jeffrey Tan via lldb-dev 
>  wrote:
> 
> Hi,
> 
> I am revising our lldb automation tests into async mode. However, I found it 
> randomly crashes depends on timing. And the crash happens mostly while 
> launching lldb twice in a row. I have narrowed down the code into a simple 
> repro below. Any assumption I made wrong with the LLDB API here?
> 
> The crash stack seems to be not consistently. In the small repro below, the 
> crash stack is:
> Crashed Thread:0  Dispatch queue: com.apple.main-thread
> 
> Exception Type:EXC_BAD_ACCESS (SIGSEGV)
> Exception Codes:   EXC_I386_GPFLT
> 
> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
> 0   _lldb.so  0x0001088c7179 
> EventMatcher::operator()(std::__1::shared_ptr const&) 
> const + 21
> 1   _lldb.so  0x0001088c65d2 
> lldb_private::Listener::FindNextEventInternal(lldb_private::Broadcaster*, 
> lldb_private::ConstString const*, unsigned int, unsigned int, 
> std::__1::shared_ptr&, bool) + 176
> 2   _lldb.so  0x0001088c6952 
> lldb_private::Listener::WaitForEventsInternal(lldb_private::TimeValue const*, 
> lldb_private::Broadcaster*, lldb_private::ConstString const*, unsigned int, 
> unsigned int, std::__1::shared_ptr&) + 134
> 3   _lldb.so  0x0001088c6ae9 
> lldb_private::Listener::WaitForEventForBroadcasterWithType(lldb_private::TimeValue
>  const*, lldb_private::Broadcaster*, unsigned int, 
> std::__1::shared_ptr&) + 27
> 4   _lldb.so  0x000108abce6c 
> lldb_private::Process::WaitForStateChangedEvents(lldb_private::TimeValue 
> const*, std::__1::shared_ptr&, lldb_private::Listener*) 
> + 112
> 5   _lldb.so  0x000108abcc95 
> lldb_private::Process::WaitForProcessToStop(lldb_private::TimeValue const*, 
> std::__1::shared_ptr*, bool, lldb_private::Listener*, 
> lldb_private::Stream*) + 377
> 6   _lldb.so  0x000108ac516a 
> lldb_private::Process::HaltForDestroyOrDetach(std::__1::shared_ptr&)
>  + 216
> 7   _lldb.so  0x000108abc8b0 
> lldb_private::Process::Destroy(bool) + 146
> 8   _lldb.so  0x000108abc56d 
> lldb_private::Process::Finalize() + 91
> 9   _lldb.so  0x0001088b63c4 
> lldb_private::Debugger::Clear() + 148
> 10  _lldb.so  0x0001088b61fd 
> lldb_private::Debugger::Destroy(std::__1::shared_ptr&)
>  + 37
> 11  _lldb.so  0x000106bdb144 
> lldb::SBDebugger::Destroy(lldb::SBDebugger&) + 116
> 12  _lldb.so  0x000106c23daf 
> _wrap_SBDebugger_Destroy(_object*, _object*) + 120
> 13  org.python.python 0x0001058dd75f PyEval_EvalFrameEx + 
> 12761
> 
> while in the real unit test it is crashing at:
> Thread 12 Crashed:
> 0   libsystem_kernel.dylib0x7fff8635a286 __pthread_kill + 10
> 1   libsystem_c.dylib 0x7fff919409b3 abort + 129
> 2   libc++abi.dylib   0x7fff8a94ea21 abort_message + 257
> 3   libc++abi.dylib   0x7fff8a9769d1 
> default_terminate_handler() + 267
> 4   libobjc.A.dylib   0x7fff935e77eb _objc_terminate() + 
> 124
> 5   libc++abi.dylib   0x7fff8a9740a1 
> std::__terminate(void (*)()) + 8
> 6   libc++abi.dylib   0x7fff8a973b30 __cxa_throw + 121
> 7   com.apple.LLDB.framework  0x00010b994c6b 
> std::__1::shared_ptr::shared_ptr(std::__1::weak_ptr
>  const&, std::__1::enable_if lldb_private::Process*>::value, 
> std::__1::shared_ptr::__nat>::type) + 99
> 8   com.apple.LLDB.framework  0x00010b8ac762 
> lldb_private::Process::AppendSTDOUT(char const*, unsigned long) + 86
> 9   com.apple.LLDB.framework  0x00010b6951d7 
> lldb_private::Communication::ReadThread(void*) + 287
> 10  libsystem_pthread.dylib   0x7fff8d92c05a _pthread_body + 131
> 11  libsystem_pthread.dylib   0x7fff8d92bfd7 _pthread_start + 176
> 
> 
> Repro Code
> 
> def wait_for_process_stop(process):
> while not process.is_stopped:
> time.sleep(0.1)
> 
> def launch_debugging(debugger, stop_at_entry):
> error = lldb.SBError()
> listener = lldb.SBListener('Chrome Dev Tools Listener')
> target = debugger.GetSelectedTarget()
> process = target.Launch (listener,
> None,  # argv
> None,  # envp
> None,  # stdin_path

Re: [lldb-dev] Race condition crashes during launching LLDB

[Jeffrey Tan via lldb-dev]

After adding some logging I figured out that the race condition is caused
by process.Continue() did not guarantee process has been really resumed yet
in async mode, so the second wait_for_process_stop() is skipped immediately
to kill listener thread and destroying debugger. I know I have a race
condition bug here because of polling for process state, but why is lldb
crashing when listener thread has exited and SBDebugger.Destroy() is
called? What is the situation that SBDebugger.Destroy() can be called
safely?

==do_test==
Launch result: success
 Listening Thread ID: 4660334592
WaitForEvent...
Target event: ModulesLoaded
WaitForEvent...
Process event: StateChanged, Stopped
Stop reason: 5
WaitForEvent...
Breakpoint event: [Added] SBBreakpoint: id = 1, name = 'main', locations = 1
WaitForEvent...
[main] killing listener thread
 Process event: StateChanged, Running
Stop reason: 0
 Exiting listener thread
[main] destroy debugger
Segmentation fault: 11

On Thu, Feb 4, 2016 at 8:22 PM, Jeffrey Tan  wrote:

> Sorry, I have actually tried to exit the event listening thread before
> debugger destroy, but still go the crash randomly(1 out of 5 runs). Here is
> the code:
>
>
> ==Main Thread==
> def wait_for_process_stop(process):
> while not process.is_stopped:
> time.sleep(0.1)
>
> def launch_debugging(debugger, stop_at_entry):
> error = lldb.SBError()
> listener = lldb.SBListener('Chrome Dev Tools Listener')
> target = debugger.GetSelectedTarget()
> process = target.Launch (listener,
> None,  # argv
> None,  # envp
> None,  # stdin_path
> None,  # stdout_path
> None,  # stderr_path
> None,  # working directory
> 0, # launch flags
> stop_at_entry,  # Stop at entry
> error) # error
> print 'Launch result: %s' % str(error)
> listener_thread = LLDBListenerThread(debugger)
> listener_thread.start()
> return listener_thread
>
> def do_test():
> debugger = lldb.SBDebugger.Create()
> debugger.SetAsync(True)
> executable_path =
> '~/Personal/compiler/CompilerConstruction/code/compiler'
> target = debugger.CreateTargetWithFileAndArch(executable_path,
> lldb.LLDB_ARCH_DEFAULT)
>
> listener_thread = launch_debugging(debugger, stop_at_entry=True)
> process = debugger.GetSelectedTarget().process
>
> wait_for_process_stop(process) # wait for entry breakpoint.
> target.BreakpointCreateByName('main')
> process.Continue()
> wait_for_process_stop(process) # wait for main breakpoint.
>
> listener_thread.should_quit = True
> listener_thread.join()
>
> lldb.SBDebugger.Destroy(debugger)
>
> def main():
> do_test()
> do_test()
>
> ==Listening Thread==
> class LLDBListenerThread(Thread):
> should_quit = False
>
> def __init__(self, debugger):
>   Thread.__init__(self)
>   process = debugger.GetSelectedTarget().process
>   self.listener = debugger.GetListener()
>   self._add_listener_to_process(process)
>   self._add_listener_to_target(process.target)
>
>def _add_listener_to_target(self, target):
> # Listen for breakpoint/watchpoint events
> (Added/Removed/Disabled/etc).
> broadcaster = target.GetBroadcaster()
> mask = lldb.SBTarget.eBroadcastBitBreakpointChanged |
> lldb.SBTarget.eBroadcastBitWatchpointChanged |
> lldb.SBTarget.eBroadcastBitModulesLoaded
> broadcaster.AddListener(self.listener, mask)
>
> def _add_listener_to_process(self, process):
> # Listen for process events (Start/Stop/Interrupt/etc).
> broadcaster = process.GetBroadcaster()
> mask = lldb.SBProcess.eBroadcastBitStateChanged |
> lldb.SBProcess.eBroadcastBitSTDOUT | lldb.SBProcess.eBroadcastBitSTDERR |
> lldb.SBProcess.eBroadcastBitInterrupt
> broadcaster.AddListener(self.listener, mask)
>
> def run(self):
> while not self.should_quit:
> event = lldb.SBEvent()
> print 'WaitForEvent...'
> if self.listener.WaitForEvent(1, event):
> if lldb.SBTarget.EventIsTargetEvent(event):
> self._handle_target_event(event)
> elif lldb.SBProcess.EventIsProcessEvent(event):
> self._handle_process_event(event)
> elif lldb.SBBreakpoint.EventIsBreakpointEvent(event):
> self._handle_breakpoint_event(event)
> elif lldb.SBThread.EventIsThreadEvent(event):
> self._handle_thread_event(event)
> else:
> self._handle_unknown_event(event)
>
> _hand_XXX_event() methods just dump some logging information of the debug
> events.
>
>
> Crashed Thread:0  Dispatch queue: com.apple.main-thread
>
>