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
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
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
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
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
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
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
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
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
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
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
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
12 matches
Mail list logo