This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug threads/19742] When a thread is stopped in non-stop mode, a breakpoint can not be set in another thread
- From: "beausoleil at free dot fr" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Tue, 01 Mar 2016 07:52:38 +0000
- Subject: [Bug threads/19742] When a thread is stopped in non-stop mode, a breakpoint can not be set in another thread
- Auto-submitted: auto-generated
- References: <bug-19742-4717 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=19742
--- Comment #4 from Christophe <beausoleil at free dot fr> ---
> For example, say you have 10 threads. Thread 1 stops at a breakpoint, and
> GDB needs to step past it. GDB stops all other 9 threads, removes all
> breakpoints -- using the just-stopped thread as current thread, single-steps
> that thread, and then reinserts all breakpoints again, again using the
> thread that just finished the single-step as current thread, and then
> re-resumes all threads.
As far as I know, this is not the way it works in non-stop mode. This is
justified in breakpoint.c: "Normal breakpoints must never be removed because
they might be missed by a running thread when debugging in non-stop mode."
When observing remote exchange, one can see that a single step is performed in
the following way by gdb:
- read the instruction
- copy it at a specific place
- set PC to this place
- single step
- read PC
- set PC according to the computed difference
Thus breakpoints are never temporarily removed by gdb, and other threads are
never stopped if they don't hit the current breakpoint.
> Sounds to me that would better model those "threads" as gdb processes,
> instead of gdb threads.
I must confess that this is an option I'm considering seriously (...but
regretfully).
--
You are receiving this mail because:
You are on the CC list for the bug.