GDB extended-remote debugging and thread groups / inferiors

Raphael Zulliger <[email protected]>
Newsgroups gmane.comp.gdb.devel
Message-ID <[email protected]>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.