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 <[email protected]>:
>
>> On Feb 28, 2016, at 2:17 PM, Paul Peet <[email protected]> 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
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev