This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
GDB extended-remote debugging and thread groups / inferiors
- From: Raphael Zulliger <zulliger at indel dot ch>
- To: "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Wed, 05 Nov 2014 16:49:17 +0100
- Subject: GDB extended-remote debugging and thread groups / inferiors
- Authentication-results: sourceware.org; auth=none
Hi
Does GDB support thread groups and/or inferiors with extended-remote
debugging? I've read several texts related to that topic
(https://sourceware.org/ml/gdb/2013-05/msg00082.html and follow-ups,
https://sourceware.org/gdb/wiki/MultiTarget,
https://sourceware.org/gdb/wiki/MultiProcess?highlight=%28OngoingWork%29
and the official docs of course) - but I'm still very unsure whether
what I'm trying to do should be working or not.
My situation:
- GDB 7.6.50.20130604-cvs
- My own GDBStub (supporting, among others:
multiprocess+;qXfer:threads:read+;qXfer:osdata:read+;)
- using 'target extended-remote' to connect
- finally debugging a self-made multi-threaded MMU-less RTOS. All
threads (kernel & user) run in the same address space (and therefore
this system doesn't have 'real processes', just threads)
Recently, we introduced dual-core systems. When we run them in SMP mode
we'd like to have 2 distinct GDB thread groups (because we finally we'd
like to have our threads grouped by the CPU cores e.g. in Eclipse/CDT,
because knowing which thread runs on which core is crucial in our case)
I tried several things:
- Played with clone-inferior, add-inferior, etc.: I therefore extended
my stub to return a process list with two 'virtual processes' with PID 1
& 2, one for each core. But I don't see how I can use the *-inferior
commands to attach to one of these "processes"
- I tried -target-attach with no success either: This command caused
the formerly debugged inferior to be killed before attaching to the second
- I modified my stub so that it returns a thread list in which the
threads of the different cores are part of a different PID (see the
p1.xxx vs p2.xxx): $qXfer:threads:read:: => ...<thread id="p1.6a0b78"
core="0">Idle</thread><thread id="p2.6a5188"
core="1">Startup</thread>... without success: GDB crashes because it
only creates one inferior (instead of two)
=> All these things make me think that I either misunderstood the
purpose and/or usage of 'thread groups' and 'inferiors' or these things
are still not properly supported for remote debugging. Can someone help
me by giving some hints?
Thanks in advance,
Raphael