[uClinux-dev] gdbserver kills the shell?

John Williams jwilliams at itee.uq.edu.au
Tue Oct 4 03:22:55 EDT 2005


Is it typical for gdbserver to take down the controlling shell when it 

I'm getting gdbserver going for microblaze, and the basic functinality 
is coming together.  However, when gdbserver exists, the shell it was 
launched from also dies, returning me to the login prompt.  Not 
critical, but distracting and suggests of deeper bugs.

I modifed the existing kernel signal debug tracing to identify who is 
sending signals (processes or the kernel itself)

Here's what happens with gdbserver (even if, as in this example, I try 
to debug a non-existent executable):

# gdbserver foo bar
Process bar created; pid = 54

SIG queue KERNEL  -> (gdbserver:53): 17  0 -> 0

(gdbserver) Child exited with retcode = 7f

SIG queue KERNEL  -> (sh:52): 17  0 -> 0

SIG queue KERNEL  -> (sh:52): 1  0 -> 0
SIG queue KERNEL  -> (sh:52): 18  0 -> 0
SIG queue KERNEL  -> (init:1): 17  0 -> 0

uclinux-auto login:
SIG queue KERNEL  -> (init:1): 14  1 -> 0
SIG dequeue (init:1): 1  0 -> 14
SIG deliver (init:1): sig=14, sp=27f8fd18 pc=27f751d0

It looks like when the exec()d child (the non-existent "bar") exists, 
the kernel sends SIGCHLD to gdbserver, that make sense

the kernel then sends SIGCHLD to the controlling shell, which also makes 
sense, since gdbserver has exited.

But then, the kernel sends SIGHUP to the shell, followed bu SIGCONT, and 
down we go.  init respawns a login prompt.

Anyway that's a lot of detail, can anybody comment on gdbserver's exit 
behaviour on other NOMMU targets?  I'm using the version that is in the 
latest uClinux-dist CVS head.



More information about the uClinux-dev mailing list