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: [PATCH 3/8] Deliver signal in hardware single step


On 03/11/2016 11:05 AM, Pedro Alves wrote:
On 03/04/2016 10:44 AM, Yao Qi wrote:
GDBserver doesn't deliver signal when stepping over a breakpoint even
hardware single step is used.  When GDBserver started to step over
(thread creation) breakpoint for mutlit-threaded debugging in 2002 [1],
GDBserver behaves this way.

This behaviour gets trouble on conditional breakpoints on branch to
self instruction like this,

     0x00000000004005b6 <+29>:	jmp    0x4005b6 <main+29>

and I set breakpoint

$(gdb) break branch-to-self.c:43 if counter > 3

and the variable counter will be set to 5 in SIGALRM signal handler.
Since GDBserver keeps stepping over breakpoint, the SIGALRM can never
be dequeued and delivered to the inferior, so the program can't stop.
The test can be found in gdb.base/branch-to-self.exp.

I can understand why does GDBserver queue signal for software single
step, but I can't figure out a reason we should queue signal for
hardware single step.  With this patch applied, GDBserver forward the
signal to inferior and the program can stop correctly.

[1] PATCH: Multithreaded debugging for gdbserver
      https://sourceware.org/ml/gdb-patches/2002-06/msg00157.html


Because the signal handler might recurse and call the same code
that had the breakpoint (or some other removed breakpoint), and thus
we'd miss a breakpoint hit in the signal handler.

Hmm, no, I got confused. We'll stop in first instruction in the signal handler. Let me go back and take a fresh look.

Thanks,
Pedro Alves


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