This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Wed, Dec 17, 2008 at 11:14 AM, Ulrich Weigand <uweigand@de.ibm.com> wrote:
> Doug Evans wrote:
>
>> > The problem arises when scheduler locking is switched on.  Actually,
>> > I think there are really two problems.  First of all, after we've
>> > switched back and single-stepped over an already-hit breakpoint via
>> > the prepare_to_proceed logic, we'll continue only a single thread
>> > if scheduler-locking is on -- and that is the wrong thread.  The
>> > prepare_to_proceed logic only explicitly switches *back* to the
>> > user-selected thread if the user was *stepping* (that's the
>> > deferred_step_ptid logic).  For scheduler-locking, we should probably
>> > switch back always ...
>>
>> If scheduler locking is on, why is there any switching at all?  If
>> scheduler-locking is on and I switch threads I'd want gdb to defer
>> single-stepping the other thread over its breakpoint until the point
>> when I make that other thread runnable.
>>
>> Also, I think removing the notion of one previously stopped thread and
>> generalizing it to not caring, i.e. checking the status of every
>> stopped thread before resuming will simplify things and fix a few bugs
>> along the way.  IOW, make deferred_ptid go away.
>
> That may indeed be the best solution.  The simplest implementation
> might be to simply remember in a per-thread flag the fact that the
> last time this thread stopped, we reported a breakpoint at stop_pc
> (which would have to be made per-thread as well, but we'd already
> decided this should happen anyway).
>
> This information could then be consulted the next time the thread
> is made runnable again.
>
>> > The second problem is more a problem of definition: even if the
>> > first problem above were fixed, we've have to single-step the other
>> > thread at least once to get over the breakpoint.  This would seem
>> > to violate the definition of scheduler locking if interpreted
>> > absolutely strictly.  Now you could argue that as the user should
>> > never be aware of that single step, it doesn't really matter.
>>
>> I'm not sure how we necessarily have a violation of the definition of
>> scheduler locking.
>
> This is just saying the same you said in other words: "If scheduler-
> locking is on and I switch threads I'd want gdb to defer single-
> stepping the other thread over its breakpoint until the point when
> I make that other thread runnable."
>
> I.e. "definition of scheduler locking" meaning: no other thread but
> the one selected by the user runs, ever.  Today, this is not true,
> in the case of single-stepping over a breakpoint in another thread.

Hi.  Here's an updated version of the patch.
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).

Ok to check in?

2009-02-23  Doug Evans  <dje@google.com>

        * infrun.c (prepare_to_proceed): Document.  Assert !non_stop.
        If scheduler-locking is enabled, we're not going to be singlestepping
        any other previously stopped thread.

        * gdb.threads/hand-call-in-threads.exp: New file.
        * gdb.threads/hand-call-in-threads.c: New file.

Attachment: gdb-090223-schedlock-4.patch.txt
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]