* remote debugging a multi-threaded program with signal
@ 2004-03-03 15:59 Atsushi Nemoto
2004-03-19 0:09 ` Atsushi Nemoto
2004-03-19 0:09 ` Atsushi Nemoto
0 siblings, 2 replies; 20+ messages in thread
From: Atsushi Nemoto @ 2004-03-03 15:59 UTC (permalink / raw)
To: gdb-patches
[-- Attachment #1: Type: Text/Plain, Size: 3040 bytes --]
There is a program on remote-debugging a multi-threaded program which
uses signals. After receiving a signal (configured to "nostop"), the
thread which receives it resumes normally but other threads leave
stopped.
I'm using gdb/snapshots/branch/gdb-6.0.90.tar.bz2 (Mar 1) on i386-linux.
The test program to reproduce this problem is attached (sigtest.c).
It creates a thread which waits SIGUSR1 and main thread sends SIGUSR1
to the thread every 10 secs. Usual output is:
$ ./sigtest
[sigtest:26616:1024]:main
[sigtest:26618:1026]:func
[sigtest:26616:1024]:send SIGUSR1
[sigtest:26618:1026]:sigwait 10
[sigtest:26616:1024]:send SIGUSR1
[sigtest:26618:1026]:sigwait 10
...
gdb debug session log is:
(gdb) target remote localhost:50000
Remote debugging using localhost:50000
0x080480e0 in _start ()
(gdb) handle SIGUSR1 nostop
Signal Stop Print Pass to program Description
SIGUSR1 No Yes Yes User defined signal 1
(gdb) c
Continuing.
[New Thread 1024]
[New Thread 1026]
and gdbserver side log is:
$ ./gdbserver host:50000 ./sigtest
Process ./sigtest created; pid = 26599
Listening on port 50000
Remote debugging from host 127.0.0.1
[sigtest:26599:1024]:main
[sigtest:26601:1026]:func
[sigtest:26599:1024]:send SIGUSR1
[sigtest:26601:1026]:sigwait 10
(no more output)
ps output is:
$ ps a
PID TTY STAT TIME COMMAND
26598 pts/4 S 0:00 ./gdbserver host:50000 ./sigtest
26599 pts/4 T 0:00 ./sigtest
26600 pts/4 T 0:00 ./sigtest
26601 pts/4 S 0:00 ./sigtest
PID 26601 is a thread which receives SIGUSR1. This was resumed but
others are still stopped.
I tried "set remote verbose-resume-packet off" and got same results.
It seems gdbserver does not handle 'continue with signal' case
correctly. I tried to fix this problem and create a patch below, and
it seems work, but I'm not sure this is a correct fix (or correct
place).
diff -up gdb-6.0.90.org/gdb/gdbserver/server.c gdb-6.0.90/gdb/gdbserver/server.c
--- gdb-6.0.90.org/gdb/gdbserver/server.c Mon Mar 1 01:49:38 2004
+++ gdb-6.0.90/gdb/gdbserver/server.c Wed Mar 3 23:49:42 2004
@@ -235,6 +235,8 @@ handle_v_cont (char *own_buf, char *stat
cont_thread = resume_info[0].thread;
else
cont_thread = -1;
+ if (cont_thread != -1 && n == 1 && !resume_info[0].step)
+ resume_info[i].leave_stopped = 0; /* signal the thread and run others */
set_desired_inferior (0);
(*the_target->resume) (resume_info);
@@ -292,7 +294,7 @@ myresume (int step, int sig)
resume_info[n].thread = -1;
resume_info[n].step = 0;
resume_info[n].sig = 0;
- resume_info[n].leave_stopped = (cont_thread > 0);
+ resume_info[n].leave_stopped = step && (cont_thread > 0);
(*the_target->resume) (resume_info);
}
Other attached files are some session logs for gdb (set debug remote
1) and gdbserver (debug_thread = 1).
gdb.output1 and gdbserver.output1 are logs with "verbose-resume on".
gdb.output2 and gdbserver.output2 are logs with "verbose-resume off".
---
Atsushi Nemoto
[-- Attachment #2: sigtest.c --]
[-- Type: Text/Plain, Size: 849 bytes --]
#include <stdio.h>
#include <pthread.h>
#include <signal.h>
static void *func(void *arg)
{
sigset_t sig;
int s;
sigemptyset(&sig);
sigaddset(&sig, SIGUSR1);
pthread_sigmask(SIG_BLOCK, &sig, NULL);
printf("[sigtest:%d:%d]:func\n", getpid(), pthread_self());
sleep(3);
while (1) {
sigwait(&sig, &s);
printf("[sigtest:%d:%d]:sigwait %d\n", getpid(), pthread_self(), s);
}
}
int
main(int argc, char *argv[])
{
pthread_t tid;
sigset_t sig;
int s, i;
sigemptyset(&sig);
sigaddset(&sig, SIGUSR1);
pthread_sigmask(SIG_BLOCK, &sig, NULL);
printf("[sigtest:%d:%d]:main\n", getpid(), pthread_self());
pthread_create(&tid, NULL, func, (void *)0);
while (1) {
for (i = 10; (i = sleep(i)) > 0; ) /* sleep 10 sec */
;
printf("[sigtest:%d:%d]:send SIGUSR1\n", getpid(), pthread_self());
pthread_kill(tid, SIGUSR1);
}
return 0;
}
[-- Attachment #3: gdb.output1 --]
[-- Type: Text/Plain, Size: 2352 bytes --]
(gdb) target remote localhost:50000
Remote debugging using localhost:50000
0x080480e0 in _start ()
(gdb) handle SIGUSR1 nostop
Signal Stop Print Pass to program Description
SIGUSR1 No Yes Yes User defined signal 1
(gdb) set debug remote 1
(gdb) c
Continuing.
Sending packet: $vCont?#49...Ack
Packet received: vCont;c;C;s;S
Packet vCont (verbose-resume) is supported
Sending packet: $vCont;s#b8...Ack
Packet received: T0505:00000000;04:e0fbffbf;08:e2800408;thread:400;
[New Thread 1024]
Sending packet: $g#67...Ack
Packet received: 00000000000000000000000000000000e0fbffbf000000000000000000000000e280040846030000230000002b0000002b0000002b000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f03000000000000ffff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000801f0000ffffffff
Sending packet: $Z0,80480e0,1#ac...Ack
Packet received:
Packet Z0 (software-breakpoint) is NOT supported
Sending packet: $m80480e0,1#63...Ack
Packet received: 31
Sending packet: $X80480e0,0:#87...Ack
Packet received:
binary downloading NOT suppported by target
Sending packet: $M80480e0,1:cc#43...Ack
Packet received: OK
Sending packet: $vCont;c#a8...Ack
Packet received: T1e05:64f87fbf;04:48f87fbf;08:6fe70408;thread:402;
[New Thread 1026]
Sending packet: $g#67...Ack
Packet received: fcffffff0800000088fc7fbfc0f97fbf48f87fbf64f87fbfc0f97fbfc0f97fbf6fe7040897020000230000002b0000002b0000002b000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f03000000000000ffff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000801f0000b3000000
Sending packet: $vCont;C1e:402#ee...Ack
[-- Attachment #4: gdbserver.output1 --]
[-- Type: Text/Plain, Size: 3981 bytes --]
~/work$ ./gdbserver host:50000 ./sigtest
Process ./sigtest created; pid = 26290
Got an event from 26290 (57f)
stop pc (before any decrement) is 080480e0
stop pc (before any decrement) is 080480e0
Hit a (non-reinsert) breakpoint.
Listening on port 50000
Remote debugging from host 127.0.0.1
Writing ffffff80 to 080c06dc
Writing ffffffcc to 0804ac08
Writing 01 to 080b66c8
Resuming, no pending status
Resuming process 26290 (step, signal 0, stop not expected)
stop pc (before any decrement) is 080480e0
Got an event from 26290 (57f)
stop pc (before any decrement) is 080480e2
stop pc (before any decrement) is 080480e2
Hit a (non-reinsert) breakpoint.
Writing resume reply for 1024
Writing ffffffcc to 080480e0
Resuming, no pending status
Resuming process 26290 (continue, signal 0, stop not expected)
stop pc (before any decrement) is 080480e2
[sigtest:26290:1024]:main
Got an event from 26290 (57f)
stop pc (before any decrement) is 0804ac09
stop pc (before any decrement) is 0804ac09
Hit a (non-reinsert) breakpoint.
Thread creation event.
Writing 00 to 080b6acc
Attaching to thread 2049 (LWP 26291)
Writing 01 to 080b6ac8
Writing 55 to 0804ac08
Resuming process 26290 (step, signal 0, stop not expected)
pending reinsert at 0804ac08Checking for breakpoint.
stop pc (before any decrement) is 0804ac09
Removed breakpoint.
set pc to 0804ac08
stop pc (before any decrement) is 0804ac08
Got an event from 26291 (137f)
stop pc (before any decrement) is 0804e76f
Expected stop.
Resuming process 26291 (continue, signal 0, stop not expected)
stop pc (before any decrement) is 0804e76f
Got an event from 26290 (57f)
stop pc (before any decrement) is 0804ac09
stop pc (before any decrement) is 0804ac09
Reinserted breakpoint.
Writing ffffffcc to 0804ac08
Resuming process 26290 (continue, signal 0, stop not expected)
stop pc (before any decrement) is 0804ac09
stop pc (before any decrement) is 0804e76f
Ignored signal 32 for 2049 (LWP 26291).
Resuming process 26291 (continue, signal 32, stop not expected)
stop pc (before any decrement) is 0804e76f
Got an event from 26291 (57f)
stop pc (before any decrement) is 0804ac09
stop pc (before any decrement) is 0804ac09
Hit a (non-reinsert) breakpoint.
Thread creation event.
Writing 00 to bf7ffdcc
Attaching to thread 1026 (LWP 26292)
Writing 01 to bf7ffdc8
Writing 55 to 0804ac08
Resuming process 26291 (step, signal 0, stop not expected)
pending reinsert at 0804ac08Checking for breakpoint.
stop pc (before any decrement) is 0804ac09
Removed breakpoint.
set pc to 0804ac08
stop pc (before any decrement) is 0804ac08
Got an event from 26292 (137f)
stop pc (before any decrement) is 0804e76f
Expected stop.
Resuming process 26292 (continue, signal 0, stop not expected)
stop pc (before any decrement) is 0804e76f
Got an event from 26291 (57f)
stop pc (before any decrement) is 0804ac09
stop pc (before any decrement) is 0804ac09
Reinserted breakpoint.
Writing ffffffcc to 0804ac08
Resuming process 26291 (continue, signal 0, stop not expected)
stop pc (before any decrement) is 0804ac09
stop pc (before any decrement) is 0804e76f
Ignored signal 32 for 1024 (LWP 26290).
Resuming process 26290 (continue, signal 32, stop not expected)
stop pc (before any decrement) is 0804e76f
stop pc (before any decrement) is 0804e76f
Ignored signal 32 for 1026 (LWP 26292).
Resuming process 26292 (continue, signal 32, stop not expected)
stop pc (before any decrement) is 0804e76f
[sigtest:26292:1026]:func
[sigtest:26290:1024]:send SIGUSR1
Got an event from 26292 (a7f)
stop pc (before any decrement) is 0804e76f
Sending sigstop to process 26290
Sending sigstop to process 26291
Got an event from 26290 (137f)
stop pc (before any decrement) is 08053f51
Got an event from 26291 (137f)
stop pc (before any decrement) is 08054a66
Writing resume reply for 1026
Resuming, no pending status
Resuming process 26292 (continue, signal 10, stop not expected)
stop pc (before any decrement) is 0804e76f
[sigtest:26292:1026]:sigwait 10
[-- Attachment #5: gdb.output2 --]
[-- Type: Text/Plain, Size: 2418 bytes --]
(gdb) set remote verbose-resume-packet off
(gdb) target remote localhost:50000
Remote debugging using localhost:50000
0x080480e0 in _start ()
(gdb) handle SIGUSR1 nostop
Signal Stop Print Pass to program Description
SIGUSR1 No Yes Yes User defined signal 1
(gdb) set debug remote 1
(gdb) c
Continuing.
Sending packet: $Hc0#db...Ack
Packet received: OK
Sending packet: $s#73...Ack
Packet received: T0505:00000000;04:e0fbffbf;08:e2800408;thread:400;
[New Thread 1024]
Sending packet: $g#67...Ack
Packet received: 00000000000000000000000000000000e0fbffbf000000000000000000000000e280040846030000230000002b0000002b0000002b000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f03000000000000ffff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000801f0000ffffffff
Sending packet: $Z0,80480e0,1#ac...Ack
Packet received:
Packet Z0 (software-breakpoint) is NOT supported
Sending packet: $m80480e0,1#63...Ack
Packet received: 31
Sending packet: $X80480e0,0:#87...Ack
Packet received:
binary downloading NOT suppported by target
Sending packet: $M80480e0,1:cc#43...Ack
Packet received: OK
Sending packet: $Hc0#db...Ack
Packet received: OK
Sending packet: $c#63...Ack
Packet received: T1e05:64f87fbf;04:48f87fbf;08:6fe70408;thread:402;
[New Thread 1026]
Sending packet: $g#67...Ack
Packet received: fcffffff0800000088fc7fbfc0f97fbf48f87fbf64f87fbfc0f97fbfc0f97fbf6fe7040897020000230000002b0000002b0000002b000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f03000000000000ffff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000801f0000b3000000
Sending packet: $Hc402#41...Ack
Packet received: OK
Sending packet: $C1e#d9...Ack
[-- Attachment #6: gdbserver.output2 --]
[-- Type: Text/Plain, Size: 3789 bytes --]
~/work$ ./gdbserver host:50000 ./sigtest
Process ./sigtest created; pid = 26306
Got an event from 26306 (57f)
stop pc (before any decrement) is 080480e0
stop pc (before any decrement) is 080480e0
Hit a (non-reinsert) breakpoint.
Listening on port 50000
Remote debugging from host 127.0.0.1
Writing ffffff80 to 080c06dc
Writing ffffffcc to 0804ac08
Writing 01 to 080b66c8
Resuming, no pending status
Resuming process 26306 (step, signal 0, stop not expected)
stop pc (before any decrement) is 080480e0
Got an event from 26306 (57f)
stop pc (before any decrement) is 080480e2
stop pc (before any decrement) is 080480e2
Hit a (non-reinsert) breakpoint.
Writing resume reply for 1024
Writing ffffffcc to 080480e0
Resuming, no pending status
Resuming process 26306 (continue, signal 0, stop not expected)
stop pc (before any decrement) is 080480e2
[sigtest:26306:1024]:main
Got an event from 26306 (57f)
stop pc (before any decrement) is 0804ac09
stop pc (before any decrement) is 0804ac09
Hit a (non-reinsert) breakpoint.
Thread creation event.
Writing 00 to 080b6acc
Attaching to thread 2049 (LWP 26307)
Writing 01 to 080b6ac8
Writing 55 to 0804ac08
Resuming process 26306 (step, signal 0, stop not expected)
pending reinsert at 0804ac08Checking for breakpoint.
stop pc (before any decrement) is 0804ac09
Removed breakpoint.
set pc to 0804ac08
stop pc (before any decrement) is 0804ac08
Got an event from 26306 (57f)
stop pc (before any decrement) is 0804ac09
stop pc (before any decrement) is 0804ac09
Reinserted breakpoint.
Writing ffffffcc to 0804ac08
Resuming process 26306 (continue, signal 0, stop not expected)
stop pc (before any decrement) is 0804ac09
Got an event from 26307 (137f)
stop pc (before any decrement) is 0805536a
Expected stop.
Resuming process 26307 (continue, signal 0, stop not expected)
stop pc (before any decrement) is 0805536a
Got an event from 26307 (57f)
stop pc (before any decrement) is 0804ac09
stop pc (before any decrement) is 0804ac09
Hit a (non-reinsert) breakpoint.
Thread creation event.
Writing 00 to bf7ffdcc
Attaching to thread 1026 (LWP 26308)
Writing 01 to bf7ffdc8
Writing 55 to 0804ac08
Resuming process 26307 (step, signal 0, stop not expected)
pending reinsert at 0804ac08Checking for breakpoint.
stop pc (before any decrement) is 0804ac09
Removed breakpoint.
set pc to 0804ac08
stop pc (before any decrement) is 0804ac08
Got an event from 26308 (137f)
stop pc (before any decrement) is 0804e76f
Expected stop.
Resuming process 26308 (continue, signal 0, stop not expected)
stop pc (before any decrement) is 0804e76f
Got an event from 26307 (57f)
stop pc (before any decrement) is 0804ac09
stop pc (before any decrement) is 0804ac09
Reinserted breakpoint.
Writing ffffffcc to 0804ac08
Resuming process 26307 (continue, signal 0, stop not expected)
stop pc (before any decrement) is 0804ac09
stop pc (before any decrement) is 0804e76f
Ignored signal 32 for 1024 (LWP 26306).
Resuming process 26306 (continue, signal 32, stop not expected)
stop pc (before any decrement) is 0804e76f
stop pc (before any decrement) is 0804e76f
Ignored signal 32 for 1026 (LWP 26308).
Resuming process 26308 (continue, signal 32, stop not expected)
stop pc (before any decrement) is 0804e76f
[sigtest:26308:1026]:func
[sigtest:26306:1024]:send SIGUSR1
Got an event from 26308 (a7f)
stop pc (before any decrement) is 0804e76f
Sending sigstop to process 26306
Sending sigstop to process 26307
Got an event from 26306 (137f)
stop pc (before any decrement) is 08053f51
Got an event from 26307 (137f)
stop pc (before any decrement) is 08054a66
Writing resume reply for 1026
Resuming, no pending status
Resuming process 26308 (continue, signal 10, stop not expected)
stop pc (before any decrement) is 0804e76f
[sigtest:26308:1026]:sigwait 10
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: remote debugging a multi-threaded program with signal
2004-03-03 15:59 remote debugging a multi-threaded program with signal Atsushi Nemoto
@ 2004-03-19 0:09 ` Atsushi Nemoto
2004-03-04 14:58 ` Atsushi Nemoto
2004-03-04 22:28 ` Daniel Jacobowitz
2004-03-19 0:09 ` Atsushi Nemoto
1 sibling, 2 replies; 20+ messages in thread
From: Atsushi Nemoto @ 2004-03-19 0:09 UTC (permalink / raw)
To: gdb-patches
>>>>> On Thu, 04 Mar 2004 01:06:24 +0900 (JST), Atsushi Nemoto <anemo@mba.ocn.ne.jp> said:
anemo> There is a program on remote-debugging a multi-threaded program
anemo> which uses signals. After receiving a signal (configured to
anemo> "nostop"), the thread which receives it resumes normally but
anemo> other threads leave stopped.
The last packet sent to gdbserver is "$vCont;C1e:402" (see gdb.output1).
gdb's info states:
`vCont'[;ACTION[`:'TID]]... -- extended resume
Resume the inferior. Different actions may be specified for each
thread. If an action is specified with no TID, then it is applied
to any threads that don't have a specific action specified; if no
default action is specified then other threads should remain
stopped. ...
So the patcket means "continue thread 0x402 with signal 0x1e, others
remain stopped". Then current gdbserver's behavior is correct.
Following the info statements, gdb should send "$vCont;C1e:402;c" to
handle a "nostop" signal correctly?
---
Atsushi Nemoto
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: remote debugging a multi-threaded program with signal
2004-03-19 0:09 ` Atsushi Nemoto
@ 2004-03-04 14:58 ` Atsushi Nemoto
2004-03-04 22:28 ` Daniel Jacobowitz
1 sibling, 0 replies; 20+ messages in thread
From: Atsushi Nemoto @ 2004-03-04 14:58 UTC (permalink / raw)
To: gdb-patches
>>>>> On Thu, 04 Mar 2004 01:06:24 +0900 (JST), Atsushi Nemoto <anemo@mba.ocn.ne.jp> said:
anemo> There is a program on remote-debugging a multi-threaded program
anemo> which uses signals. After receiving a signal (configured to
anemo> "nostop"), the thread which receives it resumes normally but
anemo> other threads leave stopped.
The last packet sent to gdbserver is "$vCont;C1e:402" (see gdb.output1).
gdb's info states:
`vCont'[;ACTION[`:'TID]]... -- extended resume
Resume the inferior. Different actions may be specified for each
thread. If an action is specified with no TID, then it is applied
to any threads that don't have a specific action specified; if no
default action is specified then other threads should remain
stopped. ...
So the patcket means "continue thread 0x402 with signal 0x1e, others
remain stopped". Then current gdbserver's behavior is correct.
Following the info statements, gdb should send "$vCont;C1e:402;c" to
handle a "nostop" signal correctly?
---
Atsushi Nemoto
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: remote debugging a multi-threaded program with signal
2004-03-19 0:09 ` Atsushi Nemoto
2004-03-04 14:58 ` Atsushi Nemoto
@ 2004-03-04 22:28 ` Daniel Jacobowitz
2004-03-19 0:09 ` Daniel Jacobowitz
` (2 more replies)
1 sibling, 3 replies; 20+ messages in thread
From: Daniel Jacobowitz @ 2004-03-04 22:28 UTC (permalink / raw)
To: Atsushi Nemoto; +Cc: gdb-patches
On Fri, Mar 05, 2004 at 12:05:40AM +0900, Atsushi Nemoto wrote:
> >>>>> On Thu, 04 Mar 2004 01:06:24 +0900 (JST), Atsushi Nemoto <anemo@mba.ocn.ne.jp> said:
>
> anemo> There is a program on remote-debugging a multi-threaded program
> anemo> which uses signals. After receiving a signal (configured to
> anemo> "nostop"), the thread which receives it resumes normally but
> anemo> other threads leave stopped.
>
> The last packet sent to gdbserver is "$vCont;C1e:402" (see gdb.output1).
>
> gdb's info states:
>
> `vCont'[;ACTION[`:'TID]]... -- extended resume
> Resume the inferior. Different actions may be specified for each
> thread. If an action is specified with no TID, then it is applied
> to any threads that don't have a specific action specified; if no
> default action is specified then other threads should remain
> stopped. ...
>
> So the patcket means "continue thread 0x402 with signal 0x1e, others
> remain stopped". Then current gdbserver's behavior is correct.
>
> Following the info statements, gdb should send "$vCont;C1e:402;c" to
> handle a "nostop" signal correctly?
I thought you said you got the same results without verbose-resume?
Oh, I suppose you would; without verbose-resume it's pot-luck which
thread gets the signal.
If I use a pre-vCont gdb client with the current gdbserver I see:
[sigtest:30016:16384]:main
[sigtest:30018:16386]:func
[sigtest:30016:16384]:send SIGUSR1
[sigtest:30016:16384]:send SIGUSR1
[sigtest:30016:16384]:send SIGUSR1
[sigtest:30016:16384]:send SIGUSR1
[sigtest:30016:16384]:send SIGUSR1
[sigtest:30016:16384]:send SIGUSR1
[sigtest:30016:16384]:send SIGUSR1
[sigtest:30016:16384]:send SIGUSR1
This means that the signal is being delivered to the wrong thread,
since neither thread appears to be stopped. Which is what I would
expect without vCont, since vCont was intended to solve this exact
problem.
GDB's behavior with threads is a little under-specified, but code to
generate the "correct" vCont packet is definitely there. Unfortunately
it is not reached. We get this:
Breakpoint 1, remote_vcont_resume (ptid={pid = 16386, lwp = 0, tid = 0}, step=0,
siggnal=TARGET_SIGNAL_USR1) at /opt/src/gdb/src/gdb/remote.c:2461
i.e. the remote target was asked to resume only one thread.
Aha, here's the bug:
/* If it's not SIGTRAP and not a signal we want to stop for, then
continue the thread. */
if (stop_signal != TARGET_SIGNAL_TRAP && !signal_stop[stop_signal])
{
if (printed)
target_terminal_inferior ();
/* Clear the signal if it should not be passed. */
if (signal_program[stop_signal] == 0)
stop_signal = TARGET_SIGNAL_0;
target_resume (ecs->ptid, 0, stop_signal);
prepare_to_wait (ecs);
return;
}
That resumes only the thread in question. This is in
target-indepenedent code and the only reason that lin-lwp native
execution does not show the same problem is that it shortcuts around
this code completely (see lin_lwp_wait).
Could you try this instead?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
2004-03-04 Daniel Jacobowitz <drow@mvista.com>
* infrun.c (handle_inferior_event): Pass nostop signals to the
correct thread.
Index: infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.137
diff -u -p -r1.137 infrun.c
--- infrun.c 16 Feb 2004 20:49:51 -0000 1.137
+++ infrun.c 4 Mar 2004 22:27:11 -0000
@@ -1918,32 +1918,29 @@ handle_inferior_event (struct execution_
#endif
}
+ context_switch (ecs);
+
+ if (context_hook)
+ context_hook (pid_to_thread_id (ecs->ptid));
+
+ flush_cached_frames ();
+
/* If it's not SIGTRAP and not a signal we want to stop for, then
continue the thread. */
if (stop_signal != TARGET_SIGNAL_TRAP && !signal_stop[stop_signal])
{
- if (printed)
- target_terminal_inferior ();
-
/* Clear the signal if it should not be passed. */
if (signal_program[stop_signal] == 0)
stop_signal = TARGET_SIGNAL_0;
- target_resume (ecs->ptid, 0, stop_signal);
+ resume (currently_stepping (ecs), stop_signal);
prepare_to_wait (ecs);
return;
}
- /* It's a SIGTRAP or a signal we're interested in. Switch threads,
- and fall into the rest of wait_for_inferior(). */
-
- context_switch (ecs);
-
- if (context_hook)
- context_hook (pid_to_thread_id (ecs->ptid));
-
- flush_cached_frames ();
+ /* It's a SIGTRAP or a signal we're interested in. Fall into the
+ rest of wait_for_inferior(). */
}
if (SOFTWARE_SINGLE_STEP_P () && singlestep_breakpoints_inserted_p)
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: remote debugging a multi-threaded program with signal
2004-03-04 22:28 ` Daniel Jacobowitz
@ 2004-03-19 0:09 ` Daniel Jacobowitz
2004-03-19 0:09 ` Atsushi Nemoto
2004-03-19 0:09 ` Atsushi Nemoto
2 siblings, 0 replies; 20+ messages in thread
From: Daniel Jacobowitz @ 2004-03-19 0:09 UTC (permalink / raw)
To: Atsushi Nemoto; +Cc: gdb-patches
On Fri, Mar 05, 2004 at 12:05:40AM +0900, Atsushi Nemoto wrote:
> >>>>> On Thu, 04 Mar 2004 01:06:24 +0900 (JST), Atsushi Nemoto <anemo@mba.ocn.ne.jp> said:
>
> anemo> There is a program on remote-debugging a multi-threaded program
> anemo> which uses signals. After receiving a signal (configured to
> anemo> "nostop"), the thread which receives it resumes normally but
> anemo> other threads leave stopped.
>
> The last packet sent to gdbserver is "$vCont;C1e:402" (see gdb.output1).
>
> gdb's info states:
>
> `vCont'[;ACTION[`:'TID]]... -- extended resume
> Resume the inferior. Different actions may be specified for each
> thread. If an action is specified with no TID, then it is applied
> to any threads that don't have a specific action specified; if no
> default action is specified then other threads should remain
> stopped. ...
>
> So the patcket means "continue thread 0x402 with signal 0x1e, others
> remain stopped". Then current gdbserver's behavior is correct.
>
> Following the info statements, gdb should send "$vCont;C1e:402;c" to
> handle a "nostop" signal correctly?
I thought you said you got the same results without verbose-resume?
Oh, I suppose you would; without verbose-resume it's pot-luck which
thread gets the signal.
If I use a pre-vCont gdb client with the current gdbserver I see:
[sigtest:30016:16384]:main
[sigtest:30018:16386]:func
[sigtest:30016:16384]:send SIGUSR1
[sigtest:30016:16384]:send SIGUSR1
[sigtest:30016:16384]:send SIGUSR1
[sigtest:30016:16384]:send SIGUSR1
[sigtest:30016:16384]:send SIGUSR1
[sigtest:30016:16384]:send SIGUSR1
[sigtest:30016:16384]:send SIGUSR1
[sigtest:30016:16384]:send SIGUSR1
This means that the signal is being delivered to the wrong thread,
since neither thread appears to be stopped. Which is what I would
expect without vCont, since vCont was intended to solve this exact
problem.
GDB's behavior with threads is a little under-specified, but code to
generate the "correct" vCont packet is definitely there. Unfortunately
it is not reached. We get this:
Breakpoint 1, remote_vcont_resume (ptid={pid = 16386, lwp = 0, tid = 0}, step=0,
siggnal=TARGET_SIGNAL_USR1) at /opt/src/gdb/src/gdb/remote.c:2461
i.e. the remote target was asked to resume only one thread.
Aha, here's the bug:
/* If it's not SIGTRAP and not a signal we want to stop for, then
continue the thread. */
if (stop_signal != TARGET_SIGNAL_TRAP && !signal_stop[stop_signal])
{
if (printed)
target_terminal_inferior ();
/* Clear the signal if it should not be passed. */
if (signal_program[stop_signal] == 0)
stop_signal = TARGET_SIGNAL_0;
target_resume (ecs->ptid, 0, stop_signal);
prepare_to_wait (ecs);
return;
}
That resumes only the thread in question. This is in
target-indepenedent code and the only reason that lin-lwp native
execution does not show the same problem is that it shortcuts around
this code completely (see lin_lwp_wait).
Could you try this instead?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
2004-03-04 Daniel Jacobowitz <drow@mvista.com>
* infrun.c (handle_inferior_event): Pass nostop signals to the
correct thread.
Index: infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.137
diff -u -p -r1.137 infrun.c
--- infrun.c 16 Feb 2004 20:49:51 -0000 1.137
+++ infrun.c 4 Mar 2004 22:27:11 -0000
@@ -1918,32 +1918,29 @@ handle_inferior_event (struct execution_
#endif
}
+ context_switch (ecs);
+
+ if (context_hook)
+ context_hook (pid_to_thread_id (ecs->ptid));
+
+ flush_cached_frames ();
+
/* If it's not SIGTRAP and not a signal we want to stop for, then
continue the thread. */
if (stop_signal != TARGET_SIGNAL_TRAP && !signal_stop[stop_signal])
{
- if (printed)
- target_terminal_inferior ();
-
/* Clear the signal if it should not be passed. */
if (signal_program[stop_signal] == 0)
stop_signal = TARGET_SIGNAL_0;
- target_resume (ecs->ptid, 0, stop_signal);
+ resume (currently_stepping (ecs), stop_signal);
prepare_to_wait (ecs);
return;
}
- /* It's a SIGTRAP or a signal we're interested in. Switch threads,
- and fall into the rest of wait_for_inferior(). */
-
- context_switch (ecs);
-
- if (context_hook)
- context_hook (pid_to_thread_id (ecs->ptid));
-
- flush_cached_frames ();
+ /* It's a SIGTRAP or a signal we're interested in. Fall into the
+ rest of wait_for_inferior(). */
}
if (SOFTWARE_SINGLE_STEP_P () && singlestep_breakpoints_inserted_p)
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: remote debugging a multi-threaded program with signal
2004-03-04 22:28 ` Daniel Jacobowitz
2004-03-19 0:09 ` Daniel Jacobowitz
@ 2004-03-19 0:09 ` Atsushi Nemoto
2004-03-05 2:25 ` Atsushi Nemoto
2004-03-19 0:09 ` Atsushi Nemoto
2004-03-19 0:09 ` Atsushi Nemoto
2 siblings, 2 replies; 20+ messages in thread
From: Atsushi Nemoto @ 2004-03-19 0:09 UTC (permalink / raw)
To: drow; +Cc: gdb-patches
>>>>> On Thu, 4 Mar 2004 17:28:00 -0500, Daniel Jacobowitz <drow@false.org> said:
drow> I thought you said you got the same results without
drow> verbose-resume? Oh, I suppose you would; without verbose-resume
drow> it's pot-luck which thread gets the signal.
drow> If I use a pre-vCont gdb client with the current gdbserver I
drow> see:
drow> [sigtest:30016:16384]:main
drow> [sigtest:30018:16386]:func
drow> [sigtest:30016:16384]:send SIGUSR1
drow> [sigtest:30016:16384]:send SIGUSR1
Oh yes, I got the same result without verbose-reume, but I did not see
any ':sigwait 10' messages on another machine.
drow> That resumes only the thread in question. This is in
drow> target-indepenedent code and the only reason that lin-lwp native
drow> execution does not show the same problem is that it shortcuts
drow> around this code completely (see lin_lwp_wait).
You mean following code in lin_lwp_wait (lin-lwp.c:1518) ?
if (signal_stop_state (signo) == 0
&& signal_print_state (signo) == 0
&& signal_pass_state (signo) == 1)
{
/* FIMXE: kettenis/2001-06-06: Should we resume all threads
here? It is not clear we should. GDB may not expect
It shourcuts the code on "noprint" case, but not on "nostop" case. So
I suppose native execution also have this problem.
drow> Could you try this instead?
Thank you. It works well with verbose-resume.
How about when verbose-resume was disabled or unavailable? If
verbose-resume is necessary to continue with signal, gdb can warn it
for users? Or gdbserver can resume all threads on this case?
---
Atsushi Nemoto
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: remote debugging a multi-threaded program with signal
2004-03-19 0:09 ` Atsushi Nemoto
@ 2004-03-05 2:25 ` Atsushi Nemoto
2004-03-19 0:09 ` Atsushi Nemoto
1 sibling, 0 replies; 20+ messages in thread
From: Atsushi Nemoto @ 2004-03-05 2:25 UTC (permalink / raw)
To: drow; +Cc: gdb-patches
>>>>> On Thu, 4 Mar 2004 17:28:00 -0500, Daniel Jacobowitz <drow@false.org> said:
drow> I thought you said you got the same results without
drow> verbose-resume? Oh, I suppose you would; without verbose-resume
drow> it's pot-luck which thread gets the signal.
drow> If I use a pre-vCont gdb client with the current gdbserver I
drow> see:
drow> [sigtest:30016:16384]:main
drow> [sigtest:30018:16386]:func
drow> [sigtest:30016:16384]:send SIGUSR1
drow> [sigtest:30016:16384]:send SIGUSR1
Oh yes, I got the same result without verbose-reume, but I did not see
any ':sigwait 10' messages on another machine.
drow> That resumes only the thread in question. This is in
drow> target-indepenedent code and the only reason that lin-lwp native
drow> execution does not show the same problem is that it shortcuts
drow> around this code completely (see lin_lwp_wait).
You mean following code in lin_lwp_wait (lin-lwp.c:1518) ?
if (signal_stop_state (signo) == 0
&& signal_print_state (signo) == 0
&& signal_pass_state (signo) == 1)
{
/* FIMXE: kettenis/2001-06-06: Should we resume all threads
here? It is not clear we should. GDB may not expect
It shourcuts the code on "noprint" case, but not on "nostop" case. So
I suppose native execution also have this problem.
drow> Could you try this instead?
Thank you. It works well with verbose-resume.
How about when verbose-resume was disabled or unavailable? If
verbose-resume is necessary to continue with signal, gdb can warn it
for users? Or gdbserver can resume all threads on this case?
---
Atsushi Nemoto
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: remote debugging a multi-threaded program with signal
2004-03-19 0:09 ` Atsushi Nemoto
2004-03-05 2:25 ` Atsushi Nemoto
@ 2004-03-19 0:09 ` Atsushi Nemoto
2004-03-05 16:36 ` Atsushi Nemoto
2004-03-05 16:38 ` Daniel Jacobowitz
1 sibling, 2 replies; 20+ messages in thread
From: Atsushi Nemoto @ 2004-03-19 0:09 UTC (permalink / raw)
To: drow; +Cc: gdb-patches
>>>>> On Fri, 05 Mar 2004 11:27:22 +0900 (JST), Atsushi Nemoto <anemo@mba.ocn.ne.jp> said:
anemo> How about when verbose-resume was disabled or unavailable? If
anemo> verbose-resume is necessary to continue with signal, gdb can
anemo> warn it for users? Or gdbserver can resume all threads on this
anemo> case?
For gdb without verbose-resume, how about this patch? With this
patch, gdbserver uses general_thread instead of all_threads.head if
'CNN' packet was sent without preceding 'HcNN'.
--- gdb-6.0.90.org/gdb/gdbserver/target.c Wed Jun 12 02:32:40 2002
+++ gdb-6.0.90/gdb/gdbserver/target.c Sat Mar 6 01:29:44 2004
@@ -49,6 +49,10 @@ set_desired_inferior (int use_general)
if (found == NULL)
found = (struct thread_info *) find_inferior_id (&all_threads,
cont_thread);
+ /* failsafe: use thread in last resume_reply */
+ if (found == NULL)
+ found = (struct thread_info *) find_inferior_id (&all_threads,
+ general_thread);
}
if (found == NULL)
---
Atsushi Nemoto
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: remote debugging a multi-threaded program with signal
2004-03-19 0:09 ` Atsushi Nemoto
@ 2004-03-05 16:36 ` Atsushi Nemoto
2004-03-05 16:38 ` Daniel Jacobowitz
1 sibling, 0 replies; 20+ messages in thread
From: Atsushi Nemoto @ 2004-03-05 16:36 UTC (permalink / raw)
To: drow; +Cc: gdb-patches
>>>>> On Fri, 05 Mar 2004 11:27:22 +0900 (JST), Atsushi Nemoto <anemo@mba.ocn.ne.jp> said:
anemo> How about when verbose-resume was disabled or unavailable? If
anemo> verbose-resume is necessary to continue with signal, gdb can
anemo> warn it for users? Or gdbserver can resume all threads on this
anemo> case?
For gdb without verbose-resume, how about this patch? With this
patch, gdbserver uses general_thread instead of all_threads.head if
'CNN' packet was sent without preceding 'HcNN'.
--- gdb-6.0.90.org/gdb/gdbserver/target.c Wed Jun 12 02:32:40 2002
+++ gdb-6.0.90/gdb/gdbserver/target.c Sat Mar 6 01:29:44 2004
@@ -49,6 +49,10 @@ set_desired_inferior (int use_general)
if (found == NULL)
found = (struct thread_info *) find_inferior_id (&all_threads,
cont_thread);
+ /* failsafe: use thread in last resume_reply */
+ if (found == NULL)
+ found = (struct thread_info *) find_inferior_id (&all_threads,
+ general_thread);
}
if (found == NULL)
---
Atsushi Nemoto
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: remote debugging a multi-threaded program with signal
2004-03-19 0:09 ` Atsushi Nemoto
2004-03-05 16:36 ` Atsushi Nemoto
@ 2004-03-05 16:38 ` Daniel Jacobowitz
2004-03-06 12:42 ` Atsushi Nemoto
2004-03-19 0:09 ` Daniel Jacobowitz
1 sibling, 2 replies; 20+ messages in thread
From: Daniel Jacobowitz @ 2004-03-05 16:38 UTC (permalink / raw)
To: Atsushi Nemoto; +Cc: gdb-patches
On Sat, Mar 06, 2004 at 01:43:43AM +0900, Atsushi Nemoto wrote:
> >>>>> On Fri, 05 Mar 2004 11:27:22 +0900 (JST), Atsushi Nemoto <anemo@mba.ocn.ne.jp> said:
>
> anemo> How about when verbose-resume was disabled or unavailable? If
> anemo> verbose-resume is necessary to continue with signal, gdb can
> anemo> warn it for users? Or gdbserver can resume all threads on this
> anemo> case?
>
> For gdb without verbose-resume, how about this patch? With this
> patch, gdbserver uses general_thread instead of all_threads.head if
> 'CNN' packet was sent without preceding 'HcNN'.
>
> --- gdb-6.0.90.org/gdb/gdbserver/target.c Wed Jun 12 02:32:40 2002
> +++ gdb-6.0.90/gdb/gdbserver/target.c Sat Mar 6 01:29:44 2004
> @@ -49,6 +49,10 @@ set_desired_inferior (int use_general)
> if (found == NULL)
> found = (struct thread_info *) find_inferior_id (&all_threads,
> cont_thread);
> + /* failsafe: use thread in last resume_reply */
> + if (found == NULL)
> + found = (struct thread_info *) find_inferior_id (&all_threads,
> + general_thread);
> }
>
> if (found == NULL)
For one thing, I'm not sure it will work. But for another, why is this
case important to you?
Without vCont the problem is fundamentally insoluble; there will always
be a case in which gdbserver mis-guesses which thread it should
continue. That's why I had to come up with a protocol change.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: remote debugging a multi-threaded program with signal
2004-03-05 16:38 ` Daniel Jacobowitz
@ 2004-03-06 12:42 ` Atsushi Nemoto
2004-03-19 0:09 ` Atsushi Nemoto
2004-03-19 0:09 ` Daniel Jacobowitz
2004-03-19 0:09 ` Daniel Jacobowitz
1 sibling, 2 replies; 20+ messages in thread
From: Atsushi Nemoto @ 2004-03-06 12:42 UTC (permalink / raw)
To: drow; +Cc: gdb-patches
>>>>> On Fri, 5 Mar 2004 11:38:54 -0500, Daniel Jacobowitz <drow@false.org> said:
>> For gdb without verbose-resume, how about this patch? With this
>> patch, gdbserver uses general_thread instead of all_threads.head if
>> 'CNN' packet was sent without preceding 'HcNN'.
drow> For one thing, I'm not sure it will work. But for another, why
drow> is this case important to you?
It solves at least my program case, and I believe it breaks nothing.
I'm still sometimes using (slightly patched) gdb 5.3. If I can solve
the problem with verbose-resume disabled in current gdb, I suppose the
fixes can be backported to gdb 5.3 easily. I already tried your fix of
infrun.c with gdb 5.3 and found it solves a part of problem.
drow> Without vCont the problem is fundamentally insoluble; there will
drow> always be a case in which gdbserver mis-guesses which thread it
drow> should continue. That's why I had to come up with a protocol
drow> change.
Hmm... then it might be better to backport all vCont stuff? Of course
upgrading to upcoming gdb 6.1 will be the best solution, but I can not
for now by some internal reason ... :-\
---
Atsushi Nemoto
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: remote debugging a multi-threaded program with signal
2004-03-06 12:42 ` Atsushi Nemoto
@ 2004-03-19 0:09 ` Atsushi Nemoto
2004-03-19 0:09 ` Daniel Jacobowitz
1 sibling, 0 replies; 20+ messages in thread
From: Atsushi Nemoto @ 2004-03-19 0:09 UTC (permalink / raw)
To: drow; +Cc: gdb-patches
>>>>> On Fri, 5 Mar 2004 11:38:54 -0500, Daniel Jacobowitz <drow@false.org> said:
>> For gdb without verbose-resume, how about this patch? With this
>> patch, gdbserver uses general_thread instead of all_threads.head if
>> 'CNN' packet was sent without preceding 'HcNN'.
drow> For one thing, I'm not sure it will work. But for another, why
drow> is this case important to you?
It solves at least my program case, and I believe it breaks nothing.
I'm still sometimes using (slightly patched) gdb 5.3. If I can solve
the problem with verbose-resume disabled in current gdb, I suppose the
fixes can be backported to gdb 5.3 easily. I already tried your fix of
infrun.c with gdb 5.3 and found it solves a part of problem.
drow> Without vCont the problem is fundamentally insoluble; there will
drow> always be a case in which gdbserver mis-guesses which thread it
drow> should continue. That's why I had to come up with a protocol
drow> change.
Hmm... then it might be better to backport all vCont stuff? Of course
upgrading to upcoming gdb 6.1 will be the best solution, but I can not
for now by some internal reason ... :-\
---
Atsushi Nemoto
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: remote debugging a multi-threaded program with signal
2004-03-06 12:42 ` Atsushi Nemoto
2004-03-19 0:09 ` Atsushi Nemoto
@ 2004-03-19 0:09 ` Daniel Jacobowitz
2004-03-06 17:11 ` Daniel Jacobowitz
2004-03-07 14:14 ` Atsushi Nemoto
1 sibling, 2 replies; 20+ messages in thread
From: Daniel Jacobowitz @ 2004-03-19 0:09 UTC (permalink / raw)
To: Atsushi Nemoto; +Cc: gdb-patches
On Sat, Mar 06, 2004 at 09:50:01PM +0900, Atsushi Nemoto wrote:
> >>>>> On Fri, 5 Mar 2004 11:38:54 -0500, Daniel Jacobowitz <drow@false.org> said:
>
> >> For gdb without verbose-resume, how about this patch? With this
> >> patch, gdbserver uses general_thread instead of all_threads.head if
> >> 'CNN' packet was sent without preceding 'HcNN'.
>
> drow> For one thing, I'm not sure it will work. But for another, why
> drow> is this case important to you?
>
> It solves at least my program case, and I believe it breaks nothing.
>
> I'm still sometimes using (slightly patched) gdb 5.3. If I can solve
> the problem with verbose-resume disabled in current gdb, I suppose the
> fixes can be backported to gdb 5.3 easily. I already tried your fix of
> infrun.c with gdb 5.3 and found it solves a part of problem.
>
> drow> Without vCont the problem is fundamentally insoluble; there will
> drow> always be a case in which gdbserver mis-guesses which thread it
> drow> should continue. That's why I had to come up with a protocol
> drow> change.
>
> Hmm... then it might be better to backport all vCont stuff? Of course
> upgrading to upcoming gdb 6.1 will be the best solution, but I can not
> for now by some internal reason ... :-\
Yes, I would rather you backport vCont than we add hacks to gdbserver
to guess :) I can tell you that the only changes to support vCont (as
far as I remember, anyway) were in remote.c. It was pretty simple
client-side.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: remote debugging a multi-threaded program with signal
2004-03-19 0:09 ` Daniel Jacobowitz
@ 2004-03-06 17:11 ` Daniel Jacobowitz
2004-03-07 14:14 ` Atsushi Nemoto
1 sibling, 0 replies; 20+ messages in thread
From: Daniel Jacobowitz @ 2004-03-06 17:11 UTC (permalink / raw)
To: Atsushi Nemoto; +Cc: gdb-patches
On Sat, Mar 06, 2004 at 09:50:01PM +0900, Atsushi Nemoto wrote:
> >>>>> On Fri, 5 Mar 2004 11:38:54 -0500, Daniel Jacobowitz <drow@false.org> said:
>
> >> For gdb without verbose-resume, how about this patch? With this
> >> patch, gdbserver uses general_thread instead of all_threads.head if
> >> 'CNN' packet was sent without preceding 'HcNN'.
>
> drow> For one thing, I'm not sure it will work. But for another, why
> drow> is this case important to you?
>
> It solves at least my program case, and I believe it breaks nothing.
>
> I'm still sometimes using (slightly patched) gdb 5.3. If I can solve
> the problem with verbose-resume disabled in current gdb, I suppose the
> fixes can be backported to gdb 5.3 easily. I already tried your fix of
> infrun.c with gdb 5.3 and found it solves a part of problem.
>
> drow> Without vCont the problem is fundamentally insoluble; there will
> drow> always be a case in which gdbserver mis-guesses which thread it
> drow> should continue. That's why I had to come up with a protocol
> drow> change.
>
> Hmm... then it might be better to backport all vCont stuff? Of course
> upgrading to upcoming gdb 6.1 will be the best solution, but I can not
> for now by some internal reason ... :-\
Yes, I would rather you backport vCont than we add hacks to gdbserver
to guess :) I can tell you that the only changes to support vCont (as
far as I remember, anyway) were in remote.c. It was pretty simple
client-side.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: remote debugging a multi-threaded program with signal
2004-03-19 0:09 ` Daniel Jacobowitz
2004-03-06 17:11 ` Daniel Jacobowitz
@ 2004-03-07 14:14 ` Atsushi Nemoto
2004-03-19 0:09 ` Atsushi Nemoto
1 sibling, 1 reply; 20+ messages in thread
From: Atsushi Nemoto @ 2004-03-07 14:14 UTC (permalink / raw)
To: drow; +Cc: gdb-patches
>>>>> On Sat, 6 Mar 2004 12:11:13 -0500, Daniel Jacobowitz <drow@false.org> said:
>> Hmm... then it might be better to backport all vCont stuff? Of
>> course upgrading to upcoming gdb 6.1 will be the best solution, but
>> I can not for now by some internal reason ... :-\
drow> Yes, I would rather you backport vCont than we add hacks to
drow> gdbserver to guess :) I can tell you that the only changes to
drow> support vCont (as far as I remember, anyway) were in remote.c.
drow> It was pretty simple client-side.
Thanks for your suggestion. I'll try to do it.
---
Atsushi Nemoto
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: remote debugging a multi-threaded program with signal
2004-03-07 14:14 ` Atsushi Nemoto
@ 2004-03-19 0:09 ` Atsushi Nemoto
0 siblings, 0 replies; 20+ messages in thread
From: Atsushi Nemoto @ 2004-03-19 0:09 UTC (permalink / raw)
To: drow; +Cc: gdb-patches
>>>>> On Sat, 6 Mar 2004 12:11:13 -0500, Daniel Jacobowitz <drow@false.org> said:
>> Hmm... then it might be better to backport all vCont stuff? Of
>> course upgrading to upcoming gdb 6.1 will be the best solution, but
>> I can not for now by some internal reason ... :-\
drow> Yes, I would rather you backport vCont than we add hacks to
drow> gdbserver to guess :) I can tell you that the only changes to
drow> support vCont (as far as I remember, anyway) were in remote.c.
drow> It was pretty simple client-side.
Thanks for your suggestion. I'll try to do it.
---
Atsushi Nemoto
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: remote debugging a multi-threaded program with signal
2004-03-05 16:38 ` Daniel Jacobowitz
2004-03-06 12:42 ` Atsushi Nemoto
@ 2004-03-19 0:09 ` Daniel Jacobowitz
1 sibling, 0 replies; 20+ messages in thread
From: Daniel Jacobowitz @ 2004-03-19 0:09 UTC (permalink / raw)
To: Atsushi Nemoto; +Cc: gdb-patches
On Sat, Mar 06, 2004 at 01:43:43AM +0900, Atsushi Nemoto wrote:
> >>>>> On Fri, 05 Mar 2004 11:27:22 +0900 (JST), Atsushi Nemoto <anemo@mba.ocn.ne.jp> said:
>
> anemo> How about when verbose-resume was disabled or unavailable? If
> anemo> verbose-resume is necessary to continue with signal, gdb can
> anemo> warn it for users? Or gdbserver can resume all threads on this
> anemo> case?
>
> For gdb without verbose-resume, how about this patch? With this
> patch, gdbserver uses general_thread instead of all_threads.head if
> 'CNN' packet was sent without preceding 'HcNN'.
>
> --- gdb-6.0.90.org/gdb/gdbserver/target.c Wed Jun 12 02:32:40 2002
> +++ gdb-6.0.90/gdb/gdbserver/target.c Sat Mar 6 01:29:44 2004
> @@ -49,6 +49,10 @@ set_desired_inferior (int use_general)
> if (found == NULL)
> found = (struct thread_info *) find_inferior_id (&all_threads,
> cont_thread);
> + /* failsafe: use thread in last resume_reply */
> + if (found == NULL)
> + found = (struct thread_info *) find_inferior_id (&all_threads,
> + general_thread);
> }
>
> if (found == NULL)
For one thing, I'm not sure it will work. But for another, why is this
case important to you?
Without vCont the problem is fundamentally insoluble; there will always
be a case in which gdbserver mis-guesses which thread it should
continue. That's why I had to come up with a protocol change.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: remote debugging a multi-threaded program with signal
2004-03-04 22:28 ` Daniel Jacobowitz
2004-03-19 0:09 ` Daniel Jacobowitz
2004-03-19 0:09 ` Atsushi Nemoto
@ 2004-03-19 0:09 ` Atsushi Nemoto
2004-03-05 4:15 ` Atsushi Nemoto
2 siblings, 1 reply; 20+ messages in thread
From: Atsushi Nemoto @ 2004-03-19 0:09 UTC (permalink / raw)
To: drow; +Cc: gdb-patches
>>>>> On Thu, 4 Mar 2004 17:28:00 -0500, Daniel Jacobowitz <drow@false.org> said:
> * infrun.c (handle_inferior_event): Pass nostop signals to the
> correct thread.
...
> - if (printed)
> - target_terminal_inferior ();
> -
BTW, it would be better to move those lines to the preceding #if 0 block? :-)
/* ??rehrauer: I don't understand the rationale for this code. If the
...
For now, remove the message altogether. */
#if 0
printed = 1;
target_terminal_ours_for_output ();
printf_filtered ("\nProgram received signal %s, %s.\n",
target_signal_to_name (stop_signal),
target_signal_to_string (stop_signal));
gdb_flush (gdb_stdout);
#endif
---
Atsushi Nemoto
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: remote debugging a multi-threaded program with signal
2004-03-19 0:09 ` Atsushi Nemoto
@ 2004-03-05 4:15 ` Atsushi Nemoto
0 siblings, 0 replies; 20+ messages in thread
From: Atsushi Nemoto @ 2004-03-05 4:15 UTC (permalink / raw)
To: drow; +Cc: gdb-patches
>>>>> On Thu, 4 Mar 2004 17:28:00 -0500, Daniel Jacobowitz <drow@false.org> said:
> * infrun.c (handle_inferior_event): Pass nostop signals to the
> correct thread.
...
> - if (printed)
> - target_terminal_inferior ();
> -
BTW, it would be better to move those lines to the preceding #if 0 block? :-)
/* ??rehrauer: I don't understand the rationale for this code. If the
...
For now, remove the message altogether. */
#if 0
printed = 1;
target_terminal_ours_for_output ();
printf_filtered ("\nProgram received signal %s, %s.\n",
target_signal_to_name (stop_signal),
target_signal_to_string (stop_signal));
gdb_flush (gdb_stdout);
#endif
---
Atsushi Nemoto
^ permalink raw reply [flat|nested] 20+ messages in thread
* remote debugging a multi-threaded program with signal
2004-03-03 15:59 remote debugging a multi-threaded program with signal Atsushi Nemoto
2004-03-19 0:09 ` Atsushi Nemoto
@ 2004-03-19 0:09 ` Atsushi Nemoto
1 sibling, 0 replies; 20+ messages in thread
From: Atsushi Nemoto @ 2004-03-19 0:09 UTC (permalink / raw)
To: gdb-patches
[-- Attachment #1: Type: Text/Plain, Size: 3040 bytes --]
There is a program on remote-debugging a multi-threaded program which
uses signals. After receiving a signal (configured to "nostop"), the
thread which receives it resumes normally but other threads leave
stopped.
I'm using gdb/snapshots/branch/gdb-6.0.90.tar.bz2 (Mar 1) on i386-linux.
The test program to reproduce this problem is attached (sigtest.c).
It creates a thread which waits SIGUSR1 and main thread sends SIGUSR1
to the thread every 10 secs. Usual output is:
$ ./sigtest
[sigtest:26616:1024]:main
[sigtest:26618:1026]:func
[sigtest:26616:1024]:send SIGUSR1
[sigtest:26618:1026]:sigwait 10
[sigtest:26616:1024]:send SIGUSR1
[sigtest:26618:1026]:sigwait 10
...
gdb debug session log is:
(gdb) target remote localhost:50000
Remote debugging using localhost:50000
0x080480e0 in _start ()
(gdb) handle SIGUSR1 nostop
Signal Stop Print Pass to program Description
SIGUSR1 No Yes Yes User defined signal 1
(gdb) c
Continuing.
[New Thread 1024]
[New Thread 1026]
and gdbserver side log is:
$ ./gdbserver host:50000 ./sigtest
Process ./sigtest created; pid = 26599
Listening on port 50000
Remote debugging from host 127.0.0.1
[sigtest:26599:1024]:main
[sigtest:26601:1026]:func
[sigtest:26599:1024]:send SIGUSR1
[sigtest:26601:1026]:sigwait 10
(no more output)
ps output is:
$ ps a
PID TTY STAT TIME COMMAND
26598 pts/4 S 0:00 ./gdbserver host:50000 ./sigtest
26599 pts/4 T 0:00 ./sigtest
26600 pts/4 T 0:00 ./sigtest
26601 pts/4 S 0:00 ./sigtest
PID 26601 is a thread which receives SIGUSR1. This was resumed but
others are still stopped.
I tried "set remote verbose-resume-packet off" and got same results.
It seems gdbserver does not handle 'continue with signal' case
correctly. I tried to fix this problem and create a patch below, and
it seems work, but I'm not sure this is a correct fix (or correct
place).
diff -up gdb-6.0.90.org/gdb/gdbserver/server.c gdb-6.0.90/gdb/gdbserver/server.c
--- gdb-6.0.90.org/gdb/gdbserver/server.c Mon Mar 1 01:49:38 2004
+++ gdb-6.0.90/gdb/gdbserver/server.c Wed Mar 3 23:49:42 2004
@@ -235,6 +235,8 @@ handle_v_cont (char *own_buf, char *stat
cont_thread = resume_info[0].thread;
else
cont_thread = -1;
+ if (cont_thread != -1 && n == 1 && !resume_info[0].step)
+ resume_info[i].leave_stopped = 0; /* signal the thread and run others */
set_desired_inferior (0);
(*the_target->resume) (resume_info);
@@ -292,7 +294,7 @@ myresume (int step, int sig)
resume_info[n].thread = -1;
resume_info[n].step = 0;
resume_info[n].sig = 0;
- resume_info[n].leave_stopped = (cont_thread > 0);
+ resume_info[n].leave_stopped = step && (cont_thread > 0);
(*the_target->resume) (resume_info);
}
Other attached files are some session logs for gdb (set debug remote
1) and gdbserver (debug_thread = 1).
gdb.output1 and gdbserver.output1 are logs with "verbose-resume on".
gdb.output2 and gdbserver.output2 are logs with "verbose-resume off".
---
Atsushi Nemoto
[-- Attachment #2: sigtest.c --]
[-- Type: Text/Plain, Size: 849 bytes --]
#include <stdio.h>
#include <pthread.h>
#include <signal.h>
static void *func(void *arg)
{
sigset_t sig;
int s;
sigemptyset(&sig);
sigaddset(&sig, SIGUSR1);
pthread_sigmask(SIG_BLOCK, &sig, NULL);
printf("[sigtest:%d:%d]:func\n", getpid(), pthread_self());
sleep(3);
while (1) {
sigwait(&sig, &s);
printf("[sigtest:%d:%d]:sigwait %d\n", getpid(), pthread_self(), s);
}
}
int
main(int argc, char *argv[])
{
pthread_t tid;
sigset_t sig;
int s, i;
sigemptyset(&sig);
sigaddset(&sig, SIGUSR1);
pthread_sigmask(SIG_BLOCK, &sig, NULL);
printf("[sigtest:%d:%d]:main\n", getpid(), pthread_self());
pthread_create(&tid, NULL, func, (void *)0);
while (1) {
for (i = 10; (i = sleep(i)) > 0; ) /* sleep 10 sec */
;
printf("[sigtest:%d:%d]:send SIGUSR1\n", getpid(), pthread_self());
pthread_kill(tid, SIGUSR1);
}
return 0;
}
[-- Attachment #3: gdb.output1 --]
[-- Type: Text/Plain, Size: 2352 bytes --]
(gdb) target remote localhost:50000
Remote debugging using localhost:50000
0x080480e0 in _start ()
(gdb) handle SIGUSR1 nostop
Signal Stop Print Pass to program Description
SIGUSR1 No Yes Yes User defined signal 1
(gdb) set debug remote 1
(gdb) c
Continuing.
Sending packet: $vCont?#49...Ack
Packet received: vCont;c;C;s;S
Packet vCont (verbose-resume) is supported
Sending packet: $vCont;s#b8...Ack
Packet received: T0505:00000000;04:e0fbffbf;08:e2800408;thread:400;
[New Thread 1024]
Sending packet: $g#67...Ack
Packet received: 00000000000000000000000000000000e0fbffbf000000000000000000000000e280040846030000230000002b0000002b0000002b000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f03000000000000ffff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000801f0000ffffffff
Sending packet: $Z0,80480e0,1#ac...Ack
Packet received:
Packet Z0 (software-breakpoint) is NOT supported
Sending packet: $m80480e0,1#63...Ack
Packet received: 31
Sending packet: $X80480e0,0:#87...Ack
Packet received:
binary downloading NOT suppported by target
Sending packet: $M80480e0,1:cc#43...Ack
Packet received: OK
Sending packet: $vCont;c#a8...Ack
Packet received: T1e05:64f87fbf;04:48f87fbf;08:6fe70408;thread:402;
[New Thread 1026]
Sending packet: $g#67...Ack
Packet received: fcffffff0800000088fc7fbfc0f97fbf48f87fbf64f87fbfc0f97fbfc0f97fbf6fe7040897020000230000002b0000002b0000002b000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f03000000000000ffff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000801f0000b3000000
Sending packet: $vCont;C1e:402#ee...Ack
[-- Attachment #4: gdbserver.output1 --]
[-- Type: Text/Plain, Size: 3981 bytes --]
~/work$ ./gdbserver host:50000 ./sigtest
Process ./sigtest created; pid = 26290
Got an event from 26290 (57f)
stop pc (before any decrement) is 080480e0
stop pc (before any decrement) is 080480e0
Hit a (non-reinsert) breakpoint.
Listening on port 50000
Remote debugging from host 127.0.0.1
Writing ffffff80 to 080c06dc
Writing ffffffcc to 0804ac08
Writing 01 to 080b66c8
Resuming, no pending status
Resuming process 26290 (step, signal 0, stop not expected)
stop pc (before any decrement) is 080480e0
Got an event from 26290 (57f)
stop pc (before any decrement) is 080480e2
stop pc (before any decrement) is 080480e2
Hit a (non-reinsert) breakpoint.
Writing resume reply for 1024
Writing ffffffcc to 080480e0
Resuming, no pending status
Resuming process 26290 (continue, signal 0, stop not expected)
stop pc (before any decrement) is 080480e2
[sigtest:26290:1024]:main
Got an event from 26290 (57f)
stop pc (before any decrement) is 0804ac09
stop pc (before any decrement) is 0804ac09
Hit a (non-reinsert) breakpoint.
Thread creation event.
Writing 00 to 080b6acc
Attaching to thread 2049 (LWP 26291)
Writing 01 to 080b6ac8
Writing 55 to 0804ac08
Resuming process 26290 (step, signal 0, stop not expected)
pending reinsert at 0804ac08Checking for breakpoint.
stop pc (before any decrement) is 0804ac09
Removed breakpoint.
set pc to 0804ac08
stop pc (before any decrement) is 0804ac08
Got an event from 26291 (137f)
stop pc (before any decrement) is 0804e76f
Expected stop.
Resuming process 26291 (continue, signal 0, stop not expected)
stop pc (before any decrement) is 0804e76f
Got an event from 26290 (57f)
stop pc (before any decrement) is 0804ac09
stop pc (before any decrement) is 0804ac09
Reinserted breakpoint.
Writing ffffffcc to 0804ac08
Resuming process 26290 (continue, signal 0, stop not expected)
stop pc (before any decrement) is 0804ac09
stop pc (before any decrement) is 0804e76f
Ignored signal 32 for 2049 (LWP 26291).
Resuming process 26291 (continue, signal 32, stop not expected)
stop pc (before any decrement) is 0804e76f
Got an event from 26291 (57f)
stop pc (before any decrement) is 0804ac09
stop pc (before any decrement) is 0804ac09
Hit a (non-reinsert) breakpoint.
Thread creation event.
Writing 00 to bf7ffdcc
Attaching to thread 1026 (LWP 26292)
Writing 01 to bf7ffdc8
Writing 55 to 0804ac08
Resuming process 26291 (step, signal 0, stop not expected)
pending reinsert at 0804ac08Checking for breakpoint.
stop pc (before any decrement) is 0804ac09
Removed breakpoint.
set pc to 0804ac08
stop pc (before any decrement) is 0804ac08
Got an event from 26292 (137f)
stop pc (before any decrement) is 0804e76f
Expected stop.
Resuming process 26292 (continue, signal 0, stop not expected)
stop pc (before any decrement) is 0804e76f
Got an event from 26291 (57f)
stop pc (before any decrement) is 0804ac09
stop pc (before any decrement) is 0804ac09
Reinserted breakpoint.
Writing ffffffcc to 0804ac08
Resuming process 26291 (continue, signal 0, stop not expected)
stop pc (before any decrement) is 0804ac09
stop pc (before any decrement) is 0804e76f
Ignored signal 32 for 1024 (LWP 26290).
Resuming process 26290 (continue, signal 32, stop not expected)
stop pc (before any decrement) is 0804e76f
stop pc (before any decrement) is 0804e76f
Ignored signal 32 for 1026 (LWP 26292).
Resuming process 26292 (continue, signal 32, stop not expected)
stop pc (before any decrement) is 0804e76f
[sigtest:26292:1026]:func
[sigtest:26290:1024]:send SIGUSR1
Got an event from 26292 (a7f)
stop pc (before any decrement) is 0804e76f
Sending sigstop to process 26290
Sending sigstop to process 26291
Got an event from 26290 (137f)
stop pc (before any decrement) is 08053f51
Got an event from 26291 (137f)
stop pc (before any decrement) is 08054a66
Writing resume reply for 1026
Resuming, no pending status
Resuming process 26292 (continue, signal 10, stop not expected)
stop pc (before any decrement) is 0804e76f
[sigtest:26292:1026]:sigwait 10
[-- Attachment #5: gdb.output2 --]
[-- Type: Text/Plain, Size: 2418 bytes --]
(gdb) set remote verbose-resume-packet off
(gdb) target remote localhost:50000
Remote debugging using localhost:50000
0x080480e0 in _start ()
(gdb) handle SIGUSR1 nostop
Signal Stop Print Pass to program Description
SIGUSR1 No Yes Yes User defined signal 1
(gdb) set debug remote 1
(gdb) c
Continuing.
Sending packet: $Hc0#db...Ack
Packet received: OK
Sending packet: $s#73...Ack
Packet received: T0505:00000000;04:e0fbffbf;08:e2800408;thread:400;
[New Thread 1024]
Sending packet: $g#67...Ack
Packet received: 00000000000000000000000000000000e0fbffbf000000000000000000000000e280040846030000230000002b0000002b0000002b000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f03000000000000ffff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000801f0000ffffffff
Sending packet: $Z0,80480e0,1#ac...Ack
Packet received:
Packet Z0 (software-breakpoint) is NOT supported
Sending packet: $m80480e0,1#63...Ack
Packet received: 31
Sending packet: $X80480e0,0:#87...Ack
Packet received:
binary downloading NOT suppported by target
Sending packet: $M80480e0,1:cc#43...Ack
Packet received: OK
Sending packet: $Hc0#db...Ack
Packet received: OK
Sending packet: $c#63...Ack
Packet received: T1e05:64f87fbf;04:48f87fbf;08:6fe70408;thread:402;
[New Thread 1026]
Sending packet: $g#67...Ack
Packet received: fcffffff0800000088fc7fbfc0f97fbf48f87fbf64f87fbfc0f97fbfc0f97fbf6fe7040897020000230000002b0000002b0000002b000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f03000000000000ffff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000801f0000b3000000
Sending packet: $Hc402#41...Ack
Packet received: OK
Sending packet: $C1e#d9...Ack
[-- Attachment #6: gdbserver.output2 --]
[-- Type: Text/Plain, Size: 3789 bytes --]
~/work$ ./gdbserver host:50000 ./sigtest
Process ./sigtest created; pid = 26306
Got an event from 26306 (57f)
stop pc (before any decrement) is 080480e0
stop pc (before any decrement) is 080480e0
Hit a (non-reinsert) breakpoint.
Listening on port 50000
Remote debugging from host 127.0.0.1
Writing ffffff80 to 080c06dc
Writing ffffffcc to 0804ac08
Writing 01 to 080b66c8
Resuming, no pending status
Resuming process 26306 (step, signal 0, stop not expected)
stop pc (before any decrement) is 080480e0
Got an event from 26306 (57f)
stop pc (before any decrement) is 080480e2
stop pc (before any decrement) is 080480e2
Hit a (non-reinsert) breakpoint.
Writing resume reply for 1024
Writing ffffffcc to 080480e0
Resuming, no pending status
Resuming process 26306 (continue, signal 0, stop not expected)
stop pc (before any decrement) is 080480e2
[sigtest:26306:1024]:main
Got an event from 26306 (57f)
stop pc (before any decrement) is 0804ac09
stop pc (before any decrement) is 0804ac09
Hit a (non-reinsert) breakpoint.
Thread creation event.
Writing 00 to 080b6acc
Attaching to thread 2049 (LWP 26307)
Writing 01 to 080b6ac8
Writing 55 to 0804ac08
Resuming process 26306 (step, signal 0, stop not expected)
pending reinsert at 0804ac08Checking for breakpoint.
stop pc (before any decrement) is 0804ac09
Removed breakpoint.
set pc to 0804ac08
stop pc (before any decrement) is 0804ac08
Got an event from 26306 (57f)
stop pc (before any decrement) is 0804ac09
stop pc (before any decrement) is 0804ac09
Reinserted breakpoint.
Writing ffffffcc to 0804ac08
Resuming process 26306 (continue, signal 0, stop not expected)
stop pc (before any decrement) is 0804ac09
Got an event from 26307 (137f)
stop pc (before any decrement) is 0805536a
Expected stop.
Resuming process 26307 (continue, signal 0, stop not expected)
stop pc (before any decrement) is 0805536a
Got an event from 26307 (57f)
stop pc (before any decrement) is 0804ac09
stop pc (before any decrement) is 0804ac09
Hit a (non-reinsert) breakpoint.
Thread creation event.
Writing 00 to bf7ffdcc
Attaching to thread 1026 (LWP 26308)
Writing 01 to bf7ffdc8
Writing 55 to 0804ac08
Resuming process 26307 (step, signal 0, stop not expected)
pending reinsert at 0804ac08Checking for breakpoint.
stop pc (before any decrement) is 0804ac09
Removed breakpoint.
set pc to 0804ac08
stop pc (before any decrement) is 0804ac08
Got an event from 26308 (137f)
stop pc (before any decrement) is 0804e76f
Expected stop.
Resuming process 26308 (continue, signal 0, stop not expected)
stop pc (before any decrement) is 0804e76f
Got an event from 26307 (57f)
stop pc (before any decrement) is 0804ac09
stop pc (before any decrement) is 0804ac09
Reinserted breakpoint.
Writing ffffffcc to 0804ac08
Resuming process 26307 (continue, signal 0, stop not expected)
stop pc (before any decrement) is 0804ac09
stop pc (before any decrement) is 0804e76f
Ignored signal 32 for 1024 (LWP 26306).
Resuming process 26306 (continue, signal 32, stop not expected)
stop pc (before any decrement) is 0804e76f
stop pc (before any decrement) is 0804e76f
Ignored signal 32 for 1026 (LWP 26308).
Resuming process 26308 (continue, signal 32, stop not expected)
stop pc (before any decrement) is 0804e76f
[sigtest:26308:1026]:func
[sigtest:26306:1024]:send SIGUSR1
Got an event from 26308 (a7f)
stop pc (before any decrement) is 0804e76f
Sending sigstop to process 26306
Sending sigstop to process 26307
Got an event from 26306 (137f)
stop pc (before any decrement) is 08053f51
Got an event from 26307 (137f)
stop pc (before any decrement) is 08054a66
Writing resume reply for 1026
Resuming, no pending status
Resuming process 26308 (continue, signal 10, stop not expected)
stop pc (before any decrement) is 0804e76f
[sigtest:26308:1026]:sigwait 10
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2004-03-07 14:14 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-03-03 15:59 remote debugging a multi-threaded program with signal Atsushi Nemoto
2004-03-19 0:09 ` Atsushi Nemoto
2004-03-04 14:58 ` Atsushi Nemoto
2004-03-04 22:28 ` Daniel Jacobowitz
2004-03-19 0:09 ` Daniel Jacobowitz
2004-03-19 0:09 ` Atsushi Nemoto
2004-03-05 2:25 ` Atsushi Nemoto
2004-03-19 0:09 ` Atsushi Nemoto
2004-03-05 16:36 ` Atsushi Nemoto
2004-03-05 16:38 ` Daniel Jacobowitz
2004-03-06 12:42 ` Atsushi Nemoto
2004-03-19 0:09 ` Atsushi Nemoto
2004-03-19 0:09 ` Daniel Jacobowitz
2004-03-06 17:11 ` Daniel Jacobowitz
2004-03-07 14:14 ` Atsushi Nemoto
2004-03-19 0:09 ` Atsushi Nemoto
2004-03-19 0:09 ` Daniel Jacobowitz
2004-03-19 0:09 ` Atsushi Nemoto
2004-03-05 4:15 ` Atsushi Nemoto
2004-03-19 0:09 ` Atsushi Nemoto
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox