llvm dev - Feb 2016 - [LLDB] Non determinism when getting description from SBThread on an event

Hello,

I originally wrote an email to the lldb mailing list but it seems that it's
not actively maintained so my email didn't get approved.

Original Email:
>  Hello,
>
>  I am currently working on an IDE for C++ and I would like to integrate
lldb as a debugger using the C++ API but it has been difficult for me to
understand the architecture because there is no documentation available
(except doxygen which isn't helpful at all).
>  I am at the point understanding the Event system? How are Events created?
>  How can I use SBListener and SBBroadcaster? (What's the function of
SBBroadvaster).
>
>  My current code looks something like this:
>
>  SBListener listener;
>  SBProcess process = target.Launch(listener, args, env, nullptr, nullptr,
>                                    nullptr,
"/home/cynecx/dev/helloWorld",
>                                    0, true, error);
>
>  process.Continue();
>
>  StateType state = process.GetState(); // is stopped
>
>  SBEvent event;
>
>  while(true) {
>    if(listener.WaitForEvent(0xFFFFFFFF, event)) {
>      // This branch is never hit
>      SBStream stream;
>      event.GetDescription(stream);
>      std::cout << stream.GetData() << std::endl;
>    } else {
>      break;
>    }
>  }
>
>  It would help developers (IDE) a lot if there might be some
tutorials/documentation on how to use the API.
>
>  Regards,
>  Paul
I figured out what went wrong (I didn't understand how SBListener and
SBBroadcaster works but now I do).
The current problem which I don't know how to deal with is the non
determinism when getting the description of a thread when for example a
event occurs (Step-over; PlanComplete).

Code:

SBListener listener = debugger.GetListener();

SBProcess process = target.Launch(listener, args, env, nullptr, nullptr,
                                  nullptr, "/home/dev/helloWorld",
                                  0, true, error);

process.GetBroadcaster().AddListener(listener,
        SBProcess::eBroadcastBitStateChanged |
SBProcess::eBroadcastBitSTDOUT);

process.Continue();

while(true) {
  SBEvent event;

  if(listener.WaitForEvent(6, event)) {
    if(!event.IsValid()) {
      break;
    }

    SBThread thread = process.GetThreadAtIndex(0);
    StateType state = process.GetStateFromEvent(event);
    SBStream stream;

    thread.GetStatus(stream);
    event.GetDescription(stream);
    std::cout << stream.GetData() << std::endl;

    auto threadStopReason = thread.GetStopReason();

    if(event.GetType() == 1 && state == eStateStopped) {
      if(threadStopReason == eStopReasonBreakpoint) {
        uint64_t bpId = thread.GetStopReasonDataAtIndex(0);

        if(bpId == static_cast<uint64_t>(bp1.GetID())) {
          std::cout << "Stopped at breakpoint" <<
std::endl;
          thread.StepOver();
        }
      } else if (threadStopReason == eStopReasonPlanComplete) {
        std::cout << "Stopped at step" << std::endl;
      }
    }
  } else {
    break;
  }
}

This code is trying to debug an executable by stopping at a breakpoint and
then step over to the next line. The problem is that
"thread.GetStatus(stream);" is always non deterministic, in terms of,
sometimes it shows that is on line 7 (breakpoint & before step over) and
after running "thread.StepOver()" , it still says that (sometimes it
says
line 9).

Why I am seeing that behavior? (When using lldb as debugger I am getting
proper thread information.). Is it because the thread is still running, if
so why did the event pop up when the thread is not in the state to be
inspected.

As I said in my original email, a proper documentation would be really
helpful and nice but I wasn't able to find an example of how to do this
(Well, there was one in python but it used the same logic as the code
above).

It would be nice if someone could give me a short description how to use
this api properly.
Thank You.

Regards,
Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160222/95ac6d71/attachment-0001.html>