Re: [RFA] Fix hand called function when another thread has hit a bp.

["Ulrich Weigand" <uweigand@de.ibm.com>]

Doug Evans wrote:

> Hi.  Here's an updated version of the patch.

Sorry for the late reply on this!

> Handling the restart after several threads are all stopped at a
> breakpoint (via scheduler-locking = on), is left for a later patch
> (it's happens more rarely).

This patch, as far as I can see, just replaces one incorrect
behaviour with a different incorrect behaviour, right?

That is to say, in the scenario where we have

 - set scheduler-locking on
 - stop on BP in thread A
 - manually switch to thread B
 - continue execution

the behaviour today is:

 - GDB will switch back to A and single-step
 - (correctly) bypass the already-hit breakpoint in A
 - (incorrectly) continue execution thread A

i.e. the incorrect behaviour is that thread A is continued,
and not thread B.

With your patch, the behaviour is:

 - GDB (correctly) continues execution of thread B
 - but the next time thread A is run, GDB will (incorrectly)
   report a second time the same breakpoint the user already saw

Did I miss anything here?

In any case, I guess I agree that the "new" type of incorrect
behaviour is probably less bad that what we have today, so
your patch does seem to be a step forward.

Will you be working on a follow-on patch to fix the new
incorrect behaviour?


>+for { set i 1 } { $i <= $total_nr_threads } { incr i } {
>+    set thread_nr $i
>+    gdb_test "thread $thread_nr" "" "prepare to discard hand call, thread $thread_nr"
>+    set frame_number [get_dummy_frame_number]
>+    if { "$frame_number" == "" } {
>+	fail "dummy stack frame number, thread $thread_nr"
>+	setup_xfail "*-*-*"
>+	# Need something.
>+	set frame_number 0

Why do we need this xfail here?

>+# Continue one last time, the program should exit normally.
>+#
>+# ??? This currently doesn't work because gdb doesn't know how to singlestep
>+# over reported breakpoints that weren't in the last thread to run.
>+# Fixing this first requires defining what the correct behaviour is.
>+# Commented out until then.
>+#
>+# Manually set the thread back to the first thread: the program is still at
>+# the all_threads_running breakpoint, which wasn't the last thread to run,
>+# and gdb doesn't know how to singlestep over reported breakpoints that
>+# weren't in the last thread to run.
>+#gdb_test "thread 1" "" "set thread to 1, prepare to resume"
>+#
>+#gdb_continue_to_end "hand-call-in-threads"

Should the "thread 1" really be here?  It seems to me this was just an 
unsuccessful attempt to work-around the bug ...

Otherwise, the patch is OK.

Thanks,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com