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

[Doug Evans <dje at google dot com>]

On Sun, Dec 14, 2008 at 2:13 PM, Ulrich Weigand <uweigand@de.ibm.com> wrote:
> Doug Evans wrote:
>
>> >> Adding the above to the end of the testcase reveals the fact that this
>> >> patch causes gdb to lose track of the fact that it needs to single
>> >> step over the breakpoint at all_threads_running in the main thread,
>> >> and resuming execution causes the breakpoint to be hit again.  Global
>> >> state, gotta love it.
>> >>
>> >> I'm assuming non-stop mode doesn't have this problem.
>> >> Can we record in struct thread_info (or some such) the last stop
>> >> reason and before resuming with !scheduler-locking iterate over all
>> >> threads, single stepping them as necessary?  Is there a better
>> >> solution?
>> >
>> > This patch fixes the expanded hand-call-in-threads.exp testcase (which
>> > is part of the patch).  In the process I discovered a bigger problem -
>> > gdb doesn't handle resuming after more than one thread is stopped at a
>> > breakpoint.  This can happen if the user runs several threads in turn
>> > with scheduler-locking on, and then turns scheduler-locking off and
>> > resumes the program.  I wrote another testcase,
>> > multi-bp-in-threads.exp, to expose this issue.  Fixing this appears to
>> > be a much harder problem, and I think I'd like to declare partial
>> > victory with this patch ...
>
> I'm not sure this is the right approach -- how can we be sure those
> breakpoints in other threads have already been reported to the user?

Hmm, do we need a flag that says which signals have been reported?

> The original code specifically steps only over the one breakpoint that
> was reported when GDB last stopped.  If other threads hit breakpoints
> simultaneously, we *want* them to trigger again, so that they can be
> properly reported to the user ...
>
> Why does this not work for your test case?

Hmm, I think we need to distinguish which testcase we're talking about.

hand-call-in-threads.exp:
  What it does:
    - start up N threads and stop
    - set scheduler-locking on
    - hand-call a function in N threads, each of which hits a breakpoint
    - manually pop pending dummy frames
    - set scheduler-locking off
    - continue
  What it tests:
    - verify a previously hit breakpoint in a different thread is NOT
singlestepped when resuming with scheduler-locking on
    - verify manually popping all pending dummy frames works
    - verify that resuming after manually popping all pending dummy
frames works (i.e. a previously hit and reported breakpoint is not
re-reported)

multi-bp-in-threads.exp:
  What it does:
    - start up N threads and stop
    - set scheduler-locking on
    - hand-call a function in N threads, each of which hits a breakpoint
    - set scheduler-locking off
    - continue
  What it tests:
    - see what happens ... it's not clear to me what _should_ happen here

Perhaps first we should agree on what the right behavior is.
For hand-call-in-threads.exp I think the testcase is correct as is.
For multi-bp-in-threads.exp, one approach is to just define the
problem away and say that GDB's current behavior is the correct
behavior. :)