This is the mail archive of the gdb-patches@sources.redhat.com 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: schedlock.exp questions


Orjan Friberg wrote:
Daniel Jacobowitz wrote:


This is a twisty and nasty part of infrun. It is full of bugs and things that need to be rearchitected. So it's quite likely it doesn't work right.

I did some more thinking, and maybe what you suggest does apply here. The logic of it escapes me at least:


* Breakpoint is set
* Breakpoint is hit (by all threads)
* Some random thread (?) is reported by the gdbserver as stopped
* Breakpoint is deleted (leaving the other threads with a pending(*) SIGTRAP)


Now, if a software single-step architecture (CRIS) is stepped, the pending SIGTRAPs are reported by the gdbserver, but because we are single-stepping thread_hop_needed is set in handle_inferior_event, making GDB ignore the signal. Eventually, when the single-step target is reached, we'll stop.

However, if we issue a "continue" instead of a "step", the SIGTRAPs are *not* ignored, and GDB will show us as stopped due to a SIGTRAP at the now removed breakpoint for each of the threads. I fail to see why the behaviour in these two cases should be different. Is it because we can't stop half-way through an ongoing software single-step?

For a hardware single-step architecture (CRISv32), the behaviour will be the same regardless of whether we "step" or "continue" - GDB will stop when the SIGTRAPs are received by the gdbserver.

(*) pending in the sense that gdbserver hasn't informed GDB of it yet

--
Orjan Friberg
Axis Communications


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