When you say that you end up stopping on a breakpoint in another thread, do you
mean that you stop at the user breakpoint that you set on the sleep call or
that the other thread stops on the internal breakpoint associated with the step
command?
If the other thread is hitting the user breakpoint, that sounds reasonable and
it's probably just a matter of test timing whether or not it happens. That is,
you might hit the breakpoint in both threads at once and have it behave like a
single stop (except that both thread stops should be reported), or you might
hit just one and then hit the other during stepping. In the log (assuming that
Linux process logging is enabled), the case of both breakpoints being hit at
once would show up as a breakpoint event being processed while we were trying
to stop all threads.
If, on the other hand, the internal breakpoint for the step is being hit by a
thread other than the thread that's stepping, that's a problem. If that
happens the thread plan should look at the breakpoint, see that it's an
internal breakpoint associated with a particular thread, and continue silently
if the thread that hit the breakpoint is not the current thread. If that were
happening, you would see it in the log file but it would otherwise be invisible
to the user.
Incidentally, one of the changes in r166732 looks wrong. The first change in
ThreadPlanStepInRange.cpp was this:
+ if (m_stop_others == lldb::eOnlyThisThread)
stop_others = false;
+ else
+ stop_others = true;
Unless I'm reading this wrong that will cause the thread plan to run other
threads if the selected mode has requested that only the current thread be run
during stepping but will stop other threads in other case, which seems exactly
backward from what is intended.
-Andy
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Ed Maste
Sent: Thursday, September 05, 2013 2:26 PM
To: [email protected]
Subject: [lldb-dev] Running other threads while stepping
I'm making good progress with the FreeBSD target thread support, but see some
differences in behaviour between my work and the Linux support. (Thanks to
Mike Sartain for sending me debug logs of the Linux case.)
I'm using a version of Mike's pthread sample code that I've modified for
portability; it's available at
https://raw.github.com/emaste/snippets/master/mikesart_pthread.c if anyone's
interested. The test code spawns a couple of threads and sleep()s in those
threads. In my test I set breakpoints on both
sleep() calls and run the process. After hitting a breakpoint I 'step-in' or
'step-over' the sleep(), and I end up stopping on a breakpoint in another
thread, rather than moving to the next source line. Mike's log on Linux
doesn't show this; the process carries on with the next line.
SVN r166732 has the commit message "Found a couple more places where we need to
run all threads when stepping," and as described it does introduce cases where
all threads are run for a step-in or step-over.
For whatever reason this affects the ThreadPlans I encounter on FreeBSD, but
not Linux.
I'm curious about the reason this change was made, and whether the Linux
behaviour or mine is expected. I can see arguments both ways, but would expect
the behaviour to be consistent on both platforms.
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
