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] |
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] |