This is the mail archive of the gdb-prs@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]

[Bug threads/19742] When a thread is stopped in non-stop mode, a breakpoint can not be set in another thread


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.

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