Non-intrusive remote GDB

Non-intrusive remote GDB

[Shrikanth Kamath]

I have a chassis that contains a i386 machine and a forwarding plane
that is PPC with a minimal micro-kernel running on it.
I can remote GDB from the i386 to the PPC but here the entire control
is taken by GDB by halting the PPC plane,
My question is it possible / feasible to attempt the remote GDB attach
only to single micro kernel thread in the PPC plane
and not halt it totally? Say the other threads proceed as normal.

--
SRK

Re: Non-intrusive remote GDB

[Jan Kratochvil]

On Wed, 11 May 2011 19:40:39 +0200, Shrikanth Kamath wrote:
> My question is it possible / feasible to attempt the remote GDB attach
> only to single micro kernel thread in the PPC plane
> and not halt it totally? Say the other threads proceed as normal.

During the initial attach normally all the threads get attached and they get
stopped by the attachment.  Later you can have stopped only one specific
thread by using non-stop mode:
	$ info '(gdb)Non-Stop Mode'

To not to stop the other threads at all one needs to disallow finding
gdbserver the file libthread_db.so.1, besides reconfiguring GDB as a safe bet
you can rename/hide it on the PPC board.  `info threads' shows only the
single/initial thread.

(Assuming GNU/Linux environment on the PPC borad; you did not say.)


Regards,
Jan

Re: Non-intrusive remote GDB

[Klaus Rudolph]

Shrikanth Kamath schrieb:

> My question is it possible / feasible to attempt the remote GDB attach
> only to single micro kernel thread in the PPC plane
> and not halt it totally? Say the other threads proceed as normal.
> 

This is a question of process structure and the underlaying os.
Threads are typically "assigned" to one task and gdb attaches to the
whole task, which is "normally" sense full. Maybe a solution could be
that you use multiple tasks not threads. Under linux this is realized
simply in the clone command where you can give some flags which decide
over the process control. I have no idea how this is solved under your
micro kernel.

An other way is to look inside your gdbserver source where maybe a
thread/task list is kept. Maybe your gdbserver stops multiple threads
from one task out of the list. Maybe you can change the sources at this
point. It is not very complicated to do so.

But without knowing your os, your system calls to the os and all the
rest it is hard to help

regards
 Klaus