This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Remote debugging
- From: "luca risso" <luca_risso at hotmail dot com>
- To: drow at false dot org
- Cc: gdb at sources dot redhat dot com
- Date: Mon, 22 Mar 2004 09:40:21 +0000
- Subject: Re: Remote debugging
- Bcc:
On Fri, Mar 19, 2004 at 10:13:40AM +0000, luca risso wrote:
> Hi,
>
> I'm trying to debug an application running on a PPC board with Linux
2.4.25.
>
> I'm new about this kind of environment so please don't be surprised if
my
> question seems too silly.
> Using GDBServer I can run the program on the target and set breakpoints
to
> stop a thread.
> I seems to me that should be possible (I've still not experinced that)
also
> to stop all threads of a process on the same breakpoint.
>
> Now, is it possible someway to stop all processes running on the board?
> It would be useful when debugging processes sending messages to each
other.
> Something similar is available using psos and VxWorks environments where
> all processes seems to be "freezed" at a time.
No, it's not possible. GDB can only manage one process at a time.
By the way, every time you stop a thread, GDB arranges for all threads
in that process to stop. GDB doesn't currently support any other mode.
In this case, for such an embedded appilcation, do you think it could be
reasonable to compile all the application stuff along with the Linux kernel?
Then probably my program would appear as a kernel thread (??) so that it can
be debugged using gdb stubs for kernel debugging.
Do you see any drawback in this approach?
Is there a "standard" or "common" approach for this kind of application?
Thanks a lot. Regards.
Luca
_________________________________________________________________
Filtri antispamming e antivirus per la tua casella di posta
http://www.msn.it/msn/hotmail