Thanks for the explanation. I'll look this over tomorrow.
cheers,
pl
On 3 March 2016 at 15:23, Paul Peet <paulpee...@gmail.com> 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<uint64_t>(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 <cstddef>
> #include <cstdint>
> #include <iostream>
>
> 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, 0x0000000000400953 main`main + 35 at
> main.cpp:7, name = 'main', stop reason = breakpoint 1.1
> frame #0: 0x0000000000400953 main`main + 35 at main.cpp:7
> 4
> 5 int main() {
> 6
> -> 7 std::cout << "Hello World" << std::endl;
> 8
> 9 int i = 0;
> 10 std::cin >> i;
> 0x7f1dc4000930 Event: broadcaster = 0x55da93268068 (lldb.process),
> type = 0x00000001 (state-changed), data = { process = 0x55da93268030
> (pid = 5862), state = stopped}
> ----------
> * thread #1: tid = 5862, 0x0000000000400953 main`main + 35 at
> main.cpp:7, name = 'main', stop reason = breakpoint 1.1
> frame #0: 0x0000000000400953 main`main + 35 at main.cpp:7
> 4
> 5 int main() {
> 6
> -> 7 std::cout << "Hello World" << std::endl;
> 8
> 9 int i = 0;
> 10 std::cin >> i;
> 0x7f1dc4001640 Event: broadcaster = 0x55da93268068 (lldb.process),
> type = 0x00000001 (state-changed), data = { process = 0x55da93268030
> (pid = 5862), state = stopped}
> Stopped at breakpoint
> ----------
> Hello World
> ----------
> * thread #1: tid = 5862, 0x0000000000400978 main`main + 72 at
> main.cpp:9, name = 'main', stop reason = step over
> frame #0: 0x0000000000400978 main`main + 72 at main.cpp:9
> 6
> 7 std::cout << "Hello World" << std::endl;
> 8
> -> 9 int i = 0;
> 10 std::cin >> i;
> 11
> 12 if (i == 1) {
> 0x7f1dc4003ae0 Event: broadcaster = 0x55da93268068 (lldb.process),
> type = 0x00000001 (state-changed), data = { process = 0x55da93268030
> (pid = 5862), state = stopped}
> Stopped at step
> ----------
>
> And the one with non-determinism:
>
> * thread #1: tid = 9097, 0x0000000000400830 main`_start, name = 'main'
> frame #0: 0x0000000000400830 main`_start
> main`_start:
> 0x400830 <+0>: xorl %ebp, %ebp
> 0x400832 <+2>: movq %rdx, %r9
> 0x400835 <+5>: popq %rsi
> 0x400836 <+6>: movq %rsp, %rdx
> 0x7fbdd0000930 Event: broadcaster = 0x564549feffa8 (lldb.process),
> type = 0x00000001 (state-changed), data = { process = 0x564549feff70
> (pid = 9097), state = stopped}
> ----------
> * thread #1: tid = 9097, 0x0000000000400830 main`_start, name =
> 'main', stop reason = breakpoint 1.1
> frame #0: 0x0000000000400830 main`_start
> main`_start:
> 0x400830 <+0>: xorl %ebp, %ebp
> 0x400832 <+2>: movq %rdx, %r9
> 0x400835 <+5>: popq %rsi
> 0x400836 <+6>: movq %rsp, %rdx
> 0x7fbdd0001640 Event: broadcaster = 0x564549feffa8 (lldb.process),
> type = 0x00000001 (state-changed), data = { process = 0x564549feff70
> (pid = 9097), state = stopped}
> Stopped at breakpoint
> ----------
> Hello World
> ----------
>
> 2016-03-03 14:57 GMT+01:00 Pavel Labath <lab...@google.com>:
>> 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
>> <lldb-dev@lists.llvm.org> 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 <gclay...@apple.com>:
>>>>
>>>>> On Feb 28, 2016, at 2:17 PM, Paul Peet <paulpee...@gmail.com> 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
