* Non-intrusive remote GDB
@ 2011-05-11 17:40 Shrikanth Kamath
2011-05-15 12:52 ` Jan Kratochvil
2011-05-15 14:16 ` Klaus Rudolph
0 siblings, 2 replies; 3+ messages in thread
From: Shrikanth Kamath @ 2011-05-11 17:40 UTC (permalink / raw)
To: gdb
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Non-intrusive remote GDB
2011-05-11 17:40 Non-intrusive remote GDB Shrikanth Kamath
@ 2011-05-15 12:52 ` Jan Kratochvil
2011-05-15 14:16 ` Klaus Rudolph
1 sibling, 0 replies; 3+ messages in thread
From: Jan Kratochvil @ 2011-05-15 12:52 UTC (permalink / raw)
To: Shrikanth Kamath; +Cc: gdb
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Non-intrusive remote GDB
2011-05-11 17:40 Non-intrusive remote GDB Shrikanth Kamath
2011-05-15 12:52 ` Jan Kratochvil
@ 2011-05-15 14:16 ` Klaus Rudolph
1 sibling, 0 replies; 3+ messages in thread
From: Klaus Rudolph @ 2011-05-15 14:16 UTC (permalink / raw)
To: gdb
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2011-05-15 14:16 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-05-11 17:40 Non-intrusive remote GDB Shrikanth Kamath
2011-05-15 12:52 ` Jan Kratochvil
2011-05-15 14:16 ` Klaus Rudolph
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).