Re: [lldb-dev] How to use the C++ API? No useful documentation?
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 eStateStopped: {
static bool runOnce = false;
if(runOnce == false) {
sleep(1); // sleep a second
runOnce = true;
}
SBThread thread = process.GetThreadAtIndex(0);
SBStream stream;
As I said before that strangely it worked on the vm with kernel 4.4 so
I tried using kernel 4.4 and it still didn't work.
Next thing I did was enabling lldb's logging and what I noticed was
that when the first thread plan is being made it had wrong instruction
information that's probably because the thread was still running. So
what I tried was this runOnce with a sleep(1) and the result was as I
expected, the thread plan contained the correct instruction
information and the following breakpoints and step-overs were
correctly made.
Any chance that this issue lies deep in lldb? Would the lldb log help
to trace back the issue?
2016-02-29 19:58 GMT+01:00 Greg Clayton :
>
>> On Feb 28, 2016, at 2:17 PM, Paul Peet wrote:
>>
>> Hey,
>>
>> Just to let you know that I think I made some progress in determine the
>> problem.
>> I've basically setup an vm (archlinux, linux 4.4, lldb 3.7.1) and
>> tried the code on it. To my surprise it gave me proper output without
>> non-determinism. YEY.
>> I still don't have any idea why it's not working on my host system. I
>> might try testing linux 4.4 like I did on the vm.
>>
>> Do you have any idea/suspicion why it might not work on my system. (I
>> can provide additional information if needed).
>
> I don't. Maybe some of the linux experts out there might be able to help you.
> Are are working with top of tree LLDB sources right? You might post the exact
> linux setup you have in case that might allow people to help you out...
>
> Greg
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] [3.8 Release] RC3 has been tagged
> -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-3.8.0-rc3-mipsel-linux-gnu.tar.xz > > > > My machine died during the check-all stage and disappeared from > the > > > network. I've fixed it and am currently running the last few bits of test- > > > release.sh manually. > > > > > > Thanks, let me know how this turns out. > > > > > > So far, it sounds like there are no new issues in rc3, so I'm hoping > > > we can make that the final version for 3.8.0 real soon. > > > > > > Cheers, > > > Hans > > > > > > > 'check-all' is still killing the machine but I think I know what the > > problem is. > While investigating some of the rc2 > > problems I noticed that g++-multilib wasn't installed and this was disabling > the mips64el sanitizers. Installing this > > didn't cause problems at the time but I've noticed that some of the > mips64el sanitizer tests are very memory hungry. > > I noticed several occasions where parallel asan tests were consuming > ~200% of RAM and it would have been > > swapping heavily (on a USB2 disk) to cope. If later tests require even more > RAM then it would explain why the > > system stops responding. I'm going to uninstall g++-multilib and rebuild > > rc3. > Hopefully that will make check-all work > > again. > > It seems there's was still just enough multilib support on the machine to > trigger mips64el sanitizers again but having worked around that the parts of > lit that aren't mips64el sanitizers are working so far. llvm-lit is still > going but > big-endian mips and cross compilation was fine so I'm expecting little endian > to be ok too. It's showing an ETA of about 90 mins for the remaining tests > from clang and llvm at the moment. I'm going to run the MIPS32 sanitizer lit > tests after that. > > Overall, I think we're probably ready for final. I just can't confirm that > rc3 was > definitely ok for little endian mips yet. This has all finished now. All ok. There was one failure in rc3 that wasn't in rc2 (libc++ :: std/thread/thread.mutex/thread.lock/thread.lock.shared/thread.lock.shared.locking/lock.pass.cpp) but it's not a regression compared to 3.7.0 and a small increase in the time limit makes it pass. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] How to use the C++ API? No useful documentation?
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 13:04, Paul Peet via lldb-dev
wrote:
> 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 eStateStopped: {
> static bool runOnce = false;
> if(runOnce == false) {
> sleep(1); // sleep a second
> runOnce = true;
> }
>
> SBThread thread = process.GetThreadAtIndex(0);
> SBStream stream;
>
> As I said before that strangely it worked on the vm with kernel 4.4 so
> I tried using kernel 4.4 and it still didn't work.
>
> Next thing I did was enabling lldb's logging and what I noticed was
> that when the first thread plan is being made it had wrong instruction
> information that's probably because the thread was still running. So
> what I tried was this runOnce with a sleep(1) and the result was as I
> expected, the thread plan contained the correct instruction
> information and the following breakpoints and step-overs were
> correctly made.
>
> Any chance that this issue lies deep in lldb? Would the lldb log help
> to trace back the issue?
>
> 2016-02-29 19:58 GMT+01:00 Greg Clayton :
>>
>>> On Feb 28, 2016, at 2:17 PM, Paul Peet wrote:
>>>
>>> Hey,
>>>
>>> Just to let you know that I think I made some progress in determine the
>>> problem.
>>> I've basically setup an vm (archlinux, linux 4.4, lldb 3.7.1) and
>>> tried the code on it. To my surprise it gave me proper output without
>>> non-determinism. YEY.
>>> I still don't have any idea why it's not working on my host system. I
>>> might try testing linux 4.4 like I did on the vm.
>>>
>>> Do you have any idea/suspicion why it might not work on my system. (I
>>> can provide additional information if needed).
>>
>> I don't. Maybe some of the linux experts out there might be able to help
>> you. Are are working with top of tree LLDB sources right? You might post the
>> exact linux setup you have in case that might allow people to help you out...
>>
>> Greg
>>
>>
> ___
> 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] How to use the C++ API? No useful documentation?
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.IsValid()) {
> return 1;
> }
>
> SBTarget target = debugger.CreateTarget("/home/cynecx/dev/helloWorld/main");
>
> if(!target.IsValid()) {
> return 1;
> }
>
> SBBreakpoint bp1 = target.BreakpointCreateByLocation(
> "/home/cynecx/dev/helloWorld/main.cpp", 7);
>
> if(!bp1.IsValid()) {
> return 1;
> }
>
> bp1.SetEnabled(true);
>
> const char* args[] = { "/home/cynecx/dev/helloWorld/main", 0 };
> const char* env[] = { 0 };
>
> SBLaunchInfo launch_info(args);
> launch_info.SetEnvironmentEntries(env, true);
> launch_info.SetWorkingDirectory("/home/cynecx/dev/helloWorld");
> launch_info.SetLaunchFlags(eLaunchFlagStopAtEntry);
>
> SBError error;
> SBProcess process = target.Launch(launch_info, error);
>
> if(!process.IsValid() || !error.Success()) {
> return 1;
> }
>
> error = process.Continue();
> if(!error.Success()) {
> return 1;
> }
>
> while(true) {
> SBEvent event;
> SBListener listener = debugger.GetListener();
>
> if(listener.WaitForEvent(6, event)) {
> if(!event.IsValid()) {
> break;
> }
>
> const uint32_t event_type = event.GetType();
>
> if (!SBProcess::EventIsProcessEvent(event)) {
> continue;
> }
>
> if(event_type == SBProcess::eBroadcastBitStateChanged) {
> const StateType state = SBProcess::GetStateFromEvent(event);
>
> switch(state) {
> default:
> continue;
> case eStateStopped: {
> //static bool runOnce = false;
> //
> //if(runOnce == false) {
> // sleep(1);
> // runOnce = true;
> //}
>
> SBThread thread = process.GetThreadAtIndex(0);
> SBStream stream;
>
> thread.GetStatus(stream);
> event.GetDescription(stream);
>
> std::cout << stream.GetData() << std::endl;
>
> auto threadStopReason = thread.GetStopReason();
> if(threadStopReason == eStopReasonBreakpoint) {
> uint64_t bpId = thread.GetStopReasonDataAtIndex(0);
>
> if(bpId == static_cast(bp1.GetID())) {
> std::cout << "Stopped at breakpoint" << std::endl;
> thread.StepOver();
> }
> } else if (threadStopReason == eStopReasonPlanComplete) {
> std::cout << "Stopped at step" << std::endl;
> }
>
> break;
> }
> }
> } else if (SBProcess::eBroadcastBitSTDOUT) {
> char buffer[1024];
> size_t num_bytes = 0;
> do
> {
> num_bytes = process.GetSTDOUT(buffer, sizeof(buffer));
> if (num_bytes > 0)
> printf("%*s", (int)num_bytes, buffer);
> } while (num_bytes == sizeof(buffer));
> }
>
> std::cout << "--" << std::endl;
> } else {
> break;
> }
> }
>
> SBDebugger::Terminate();
>
> return 0;
> }
>
> main.cpp:
>
> #include
> #include
> #include
>
> int main() {
>
> std::cout << "Hello World" << std::endl;
>
> int i = 0;
> std::cin >> i;
>
> if (i == 1) {
> return 1;
> }
>
> return 0;
> }
>
>
> So the problem is that I am not getting correct thread information
> when receiving an eStateStopped event. It kinda seems that when
> "thread.GetStatus(stream);", the thread hasn't stopped yet so I always
> getting non-determine thread information.
> I found out that on my linux vm, it works properly so I thought it
> might be an issue with the kernel and stuff but I kinda found a
> workaround by simply putting a sleep(1) before querying the thread
> information. As expected it gave me correct thread information, also
> the step-over worked properly because the thread plan used correct
> line information.
>
> To compare both outputs:
>
> Correct one (with sleep(1)):
>
> * thread #1: tid = 5862, 0x00400953 main`main + 35 at
> main.cpp:7, name = 'main', stop reason = breakpoint 1.1
> frame #0: 0x00400953 main`main + 35 at main.cpp:7
>4
>5 int main() {
>6
> -> 7std::cout << "Hello World" << std::endl;
>8
>9int i = 0;
>10std::cin >> i;
> 0x7f1dc4000930 Event: broadcaster = 0x55da93268068 (lldb.process),
> type = 0x0001 (state-changed), data = { process = 0x55da93268030
> (pid = 5862), state = stopped}
> --
> * thread #1: tid = 5862, 0x00400953 main`main + 35 at
> main.cpp:7, name = 'main', stop reason = breakpoint 1.1
> frame #0: 0x00400953 main`main + 35 at main.cpp:7
>4
>5 int main() {
>6
> -> 7std::cout << "Hello World" << std::endl;
>8
>9int i = 0;
>10std::cin >> i;
>
Re: [lldb-dev] How to use the C++ API? No useful documentation?
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()) {
return 1;
}
SBBreakpoint bp1 = target.BreakpointCreateByLocation(
"/home/cynecx/dev/helloWorld/main.cpp", 7);
if(!bp1.IsValid()) {
return 1;
}
bp1.SetEnabled(true);
const char* args[] = { "/home/cynecx/dev/helloWorld/main", 0 };
const char* env[] = { 0 };
SBLaunchInfo launch_info(args);
launch_info.SetEnvironmentEntries(env, true);
launch_info.SetWorkingDirectory("/home/cynecx/dev/helloWorld");
launch_info.SetLaunchFlags(eLaunchFlagStopAtEntry);
SBError error;
SBProcess process = target.Launch(launch_info, error);
if(!process.IsValid() || !error.Success()) {
return 1;
}
error = process.Continue();
if(!error.Success()) {
return 1;
}
while(true) {
SBEvent event;
SBListener listener = debugger.GetListener();
if(listener.WaitForEvent(6, event)) {
if(!event.IsValid()) {
break;
}
const uint32_t event_type = event.GetType();
if (!SBProcess::EventIsProcessEvent(event)) {
continue;
}
if(event_type == SBProcess::eBroadcastBitStateChanged) {
const StateType state = SBProcess::GetStateFromEvent(event);
switch(state) {
default:
continue;
case eStateStopped: {
//static bool runOnce = false;
//
//if(runOnce == false) {
// sleep(1);
// runOnce = true;
//}
SBThread thread = process.GetThreadAtIndex(0);
SBStream stream;
thread.GetStatus(stream);
event.GetDescription(stream);
std::cout << stream.GetData() << std::endl;
auto threadStopReason = thread.GetStopReason();
if(threadStopReason == eStopReasonBreakpoint) {
uint64_t bpId = thread.GetStopReasonDataAtIndex(0);
if(bpId == static_cast(bp1.GetID())) {
std::cout << "Stopped at breakpoint" << std::endl;
thread.StepOver();
}
} else if (threadStopReason == eStopReasonPlanComplete) {
std::cout << "Stopped at step" << std::endl;
}
break;
}
}
} else if (SBProcess::eBroadcastBitSTDOUT) {
char buffer[1024];
size_t num_bytes = 0;
do
{
num_bytes = process.GetSTDOUT(buffer, sizeof(buffer));
if (num_bytes > 0)
printf("%*s", (int)num_bytes, buffer);
} while (num_bytes == sizeof(buffer));
}
std::cout << "--" << std::endl;
} else {
break;
}
}
SBDebugger::Terminate();
return 0;
}
main.cpp:
#include
#include
#include
int main() {
std::cout << "Hello World" << std::endl;
int i = 0;
std::cin >> i;
if (i == 1) {
return 1;
}
return 0;
}
So the problem is that I am not getting correct thread information
when receiving an eStateStopped event. It kinda seems that when
"thread.GetStatus(stream);", the thread hasn't stopped yet so I always
getting non-determine thread information.
I found out that on my linux vm, it works properly so I thought it
might be an issue with the kernel and stuff but I kinda found a
workaround by simply putting a sleep(1) before querying the thread
information. As expected it gave me correct thread information, also
the step-over worked properly because the thread plan used correct
line information.
To compare both outputs:
Correct one (with sleep(1)):
* thread #1: tid = 5862, 0x00400953 main`main + 35 at
main.cpp:7, name = 'main', stop reason = breakpoint 1.1
frame #0: 0x00400953 main`main + 35 at main.cpp:7
4
5 int main() {
6
-> 7std::cout << "Hello World" << std::endl;
8
9int i = 0;
10std::cin >> i;
0x7f1dc4000930 Event: broadcaster = 0x55da93268068 (lldb.process),
type = 0x0001 (state-changed), data = { process = 0x55da93268030
(pid = 5862), state = stopped}
--
* thread #1: tid = 5862, 0x00400953 main`main + 35 at
main.cpp:7, name = 'main', stop reason = breakpoint 1.1
frame #0: 0x00400953 main`main + 35 at main.cpp:7
4
5 int main() {
6
-> 7std::cout << "Hello World" << std::endl;
8
9int i = 0;
10std::cin >> i;
0x7f1dc4001640 Event: broadcaster = 0x55da93268068 (lldb.process),
type = 0x0001 (state-changed), data = { process = 0x55da93268030
(pid = 5862), state = stopped}
Stopped at breakpoint
--
Hello World
--
* thread #1: tid = 5862, 0x00400978 main`main + 72 at
main.cpp:9, name = 'main', stop reason = step over
frame #0: 0x00400978 main`main + 72 at main.cpp:9
6
7std::cout << "Hello World" <<
[lldb-dev] How to enumerate stopped threads in C++ API?
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 process stops, I need to identify all the threads that have
non-trivial stop reason. So, I am doing something like that:
// Loop over threadsint numThreads = m_Process.GetNumThreads();for
(int threadIndex = 0; threadIndex < numThreads; ++threadIndex){//
Inspect the thread statesbThread =
m_Process.GetThreadAtIndex(threadIndex);stopReason =
sbThread.GetStopReason();...
Well, this loop turns out to be a bottleneck.
So, is there any way to find all the stopped threads without iterating over the
whole world?
Thanks,Eugene
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] FYI: a python crash running tests
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 is > null, which leads to a call with a null this pointer. > > However, the Test Result Summary shows no problems: 0 failures, errors, > exceptional exits, and timeouts. > > I would try to debug it, but I'm about to head out. > > Adrian. > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] FYI: a python crash running tests
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: Adrian McCarthy; LLDB; Ted Woodward Subject: Re: FYI: a python crash running tests 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 mailto:amcca...@google.com> > 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 is null, which leads to a call with a null this pointer. However, the Test Result Summary shows no problems: 0 failures, errors, exceptional exits, and timeouts. I would try to debug it, but I'm about to head out. Adrian. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] [3.8 Release] 'final' has been tagged
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 on FreeBSD 10. Uploaded the following: SHA256 (clang+llvm-3.8.0-i386-unknown-freebsd10.tar.xz) = 674cf5faac18ffa5c01775460d2d56975426ea454e395332851a6a547140597e SHA256 (clang+llvm-3.8.0-amd64-unknown-freebsd10.tar.xz) = fb5784be4dca2794f1229106c102230cff45d9b00fba28d6624ff2f0009a38ff -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] How to enumerate stopped threads in C++ API?
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, at 9:54 AM, Eugene Birukov via lldb-dev
> wrote:
>
> 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 process stops, I need to identify all the threads that
> have non-trivial stop reason. So, I am doing something like that:
>
> // Loop over threads
> int numThreads = m_Process.GetNumThreads();
> for (int threadIndex = 0; threadIndex < numThreads; ++threadIndex)
> {
> // Inspect the thread state
> sbThread = m_Process.GetThreadAtIndex(threadIndex);
> stopReason = sbThread.GetStopReason();
> ...
>
>
> Well, this loop turns out to be a bottleneck.
>
> So, is there any way to find all the stopped threads without iterating over
> the whole world?
>
> Thanks,
> Eugene
>
>
> ___
> 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] How to enumerate stopped threads in C++ API?
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
{
SBThreadCollection GetThreadsWithStopReasons();
};
The current API on process SBProcess::GetNumThreads() and
SBProcess::GetThreadAtIndex() might have issues if you are doing things like
evaluating an expression on another thread where you might request the number
of threads and get 10, but then an expression runs on another thread and there
are now maybe 8 or 12 threads, and then you call SBProcess::GetThreadAtIndex()
and it might return you results that are different that what you wanted. If we
return all threads at once, we won't run into this issue. Then you can have
SBThreadCollection add a new methods to return a new list for all threads with
stop reasons.
That being said, hundreds of threads should not cause a huge bottleneck for
single stop, but if you doing it many many many times it could be.
Greg Clayton
> On Mar 3, 2016, at 9:54 AM, Eugene Birukov via lldb-dev
> wrote:
>
> 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 process stops, I need to identify all the threads that
> have non-trivial stop reason. So, I am doing something like that:
>
> // Loop over threads
> int numThreads = m_Process.GetNumThreads();
> for (int threadIndex = 0; threadIndex < numThreads; ++threadIndex)
> {
> // Inspect the thread state
> sbThread = m_Process.GetThreadAtIndex(threadIndex);
> stopReason = sbThread.GetStopReason();
> ...
>
>
> Well, this loop turns out to be a bottleneck.
>
> So, is there any way to find all the stopped threads without iterating over
> the whole world?
>
> Thanks,
> Eugene
>
>
> ___
> 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] How to enumerate stopped threads in C++ API?
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, 3 Mar 2016 12:41:16 -0800
> CC: lldb-dev@lists.llvm.org; rd...@microsoft.com
> To: eugen...@hotmail.com
>
> 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
> {
> SBThreadCollection GetThreadsWithStopReasons();
> };
>
>
> The current API on process SBProcess::GetNumThreads() and
> SBProcess::GetThreadAtIndex() might have issues if you are doing things like
> evaluating an expression on another thread where you might request the number
> of threads and get 10, but then an expression runs on another thread and
> there are now maybe 8 or 12 threads, and then you call
> SBProcess::GetThreadAtIndex() and it might return you results that are
> different that what you wanted. If we return all threads at once, we won't
> run into this issue. Then you can have SBThreadCollection add a new methods
> to return a new list for all threads with stop reasons.
>
> That being said, hundreds of threads should not cause a huge bottleneck for
> single stop, but if you doing it many many many times it could be.
>
> Greg Clayton
>
> > On Mar 3, 2016, at 9:54 AM, Eugene Birukov via lldb-dev
> > wrote:
> >
> > 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 process stops, I need to identify all the
> > threads that have non-trivial stop reason. So, I am doing something like
> > that:
> >
> > // Loop over threads
> > int numThreads = m_Process.GetNumThreads();
> > for (int threadIndex = 0; threadIndex < numThreads; ++threadIndex)
> > {
> > // Inspect the thread state
> > sbThread = m_Process.GetThreadAtIndex(threadIndex);
> > stopReason = sbThread.GetStopReason();
> > ...
> >
> >
> > Well, this loop turns out to be a bottleneck.
> >
> > So, is there any way to find all the stopped threads without iterating over
> > the whole world?
> >
> > Thanks,
> > Eugene
> >
> >
> > ___
> > 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] [Release-testers] [3.8 Release] 'final' has been tagged
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 and upload to the sftp. > > For others following along: yes, this means 3.8.0 is complete, but it > takes a couple of days to get the source and binary tarballs built. I > will send the release announcement when everything's ready. > > > Uploaded clang+llvm-3.8.0-x86_64-sles11.3-linux-gnu.tar.xz and clang+llvm-3.8.0-linux-armhf-vivid.tar.xz 7388c9ec1c9680a3366dd40e0bb8acc655b3e3ec clang+llvm-3.8.0-linux-armhf-vivid.tar.xz c33ab986d5b8dce7af88ca1b748240f98c4ed2c5 clang+llvm-3.8.0-x86_64-sles11.3-linux-gnu.tar.xz -- -Brian ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
