On Wed, Mar 2, 2016 at 6:33 PM, Hans Wennborg via Release-testers <
release-test...@lists.llvm.org> wrote:
> Dear testers,
>
> My list of blockers is empty, and there were no new problems
> discovered with rc3, so I have gone ahead and tagged 3.8.0-final [1].
>
> Please build the final binaries an
Thanks a lot! We'll try to profile what is going on, I'll let you know if we
find something.Skipping locks if possible is always nice. I'll look into
getting collection approach.
Eugene
> Subject: Re: [lldb-dev] How to enumerate stopped threads in C++ API?
> From: gclay...@apple.com
> Date: Thu,
Each call into the lldb::SB* API will take a target lock and possible a process
read/write lock.
We do have a SBThreadCollection class that we can use. Feel free to add an API
like this to SBProcess:
class SBProcess
{
SBThreadCollection GetThreads();
};
class SBThreadCollection
{
SBT
I'm surprised that this turns out to be a bottleneck. All the work to create
the threads should have been done when you stopped, so this should just be
running over a vector that already exists and pulling a field out. Can you
profile this and see what is actually slow?
Jim
> On Mar 3, 2016,
On 03 Mar 2016, at 01:33, Hans Wennborg via Release-testers
wrote:
>
> My list of blockers is empty, and there were no new problems
> discovered with rc3, so I have gone ahead and tagged 3.8.0-final [1].
>
> Please build the final binaries and upload to the sftp.
Built and tested successfully
I think I see the problem; I’ll push up a fix.
--
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: Thursday, March 03, 2016 11:54 AM
To:
Hi Ted, any chance this is your recent change? I know you had some changes
in this file recently
On Wed, Mar 2, 2016 at 4:46 PM Adrian McCarthy wrote:
> Running ninja check-lldb now has one crash in a Python process, due to
> deferencing a null pointer in IRExecutionUnit.cpp: candidate_sc.symbol
Hi,
I am working on a custom debugger on Linux and I am using LLDB C++ API for
that. So far, from the functionality point of view the life is good, but I am
running into severe performance issue.
The problem is that the target application has literally hundreds of threads,
and when the target pr
Hi Pavel,
This is the code:
int main() {
using namespace lldb;
SBDebugger::Initialize();
SBDebugger debugger = SBDebugger::Create(true);
if(!debugger.IsValid()) {
return 1;
}
SBTarget target = debugger.CreateTarget("/home/cynecx/dev/helloWorld/main");
if(!target.IsValid()) {
Thanks for the explanation. I'll look this over tomorrow.
cheers,
pl
On 3 March 2016 at 15:23, Paul Peet wrote:
> Hi Pavel,
>
> This is the code:
>
> int main() {
> using namespace lldb;
>
> SBDebugger::Initialize();
> SBDebugger debugger = SBDebugger::Create(true);
>
> if(!debugger.IsVa
Hi Paul,
I haven't followed this discussion from the start, and I am now having
trouble understanding what is the issue at hand here. Could you just
briefly repeat what is the problem, and maybe send the code for
reproducing the problem again? Maybe I'll be able to help...
pl
On 3 March 2016 at
> -Original Message-
> From: Daniel Sanders
> Sent: 02 March 2016 21:01
> To: Hans Wennborg
> Cc: release-test...@lists.llvm.org; llvm-dev; cfe-dev; openmp-dev (openmp-
> d...@lists.llvm.org); LLDB Dev
> Subject: RE: [Release-testers] [3.8 Release] RC3 has been tagged
>
> > > > clang+llvm-
Sorry to bring this up again, but I am not sure if this is really a
linux kernel issue anymore, see the following code:
if(event_type == SBProcess::eBroadcastBitStateChanged) {
const StateType state = SBProcess::GetStateFromEvent(event);
switch(state) {
default:
continue;
case e
13 matches
Mail list logo
