Re: Towards multiprocess GDB

[Joel Brobecker <brobecker at adacore dot com>]

> Please remind me, why was this a desirable capability again?

One case that Pedro and I discussed at the GCC Summit when he mentioned
this topic was VxWorks systems.

AdaCore recently re-implemented support for ppc/vxworks targets in GDB,
and I can post the diff if anyone is interested. I haven't done so yet,
because there are a couple of major hacks that we had to introduced and
I want to re-implement then appropriately before considering a submission.

VxWorks introduces the notion of partitions, but has no notion of
"process" - only "tasks" (aka threads). All tasks within a partition
have access to everything within that partition. However, partitions
can almost be viewed as different computers, so symbols in one partition
are completely irrelevant to other partitions.

One way to debug some of the code is to debug one task, and treat it
as a process. But the reality is that programs are often multi-threaded
and so debugging one task would only be debugging part the program.
This is why we introduced the option of debugging the entire partition
as one process.

But most of our users want to debug the entire system rather than each
individual task separately, because of inter-partition scheduling or
communication issues. This is when the fun starts, because we now have
symbols for one partition, and symbols for another partition, and we
need to remember which partition they are for.  I believe that adding
support for multi-process debugging will solve the issue above, since
each process should have its own list of objfiles and associated
symbols.

VxWorks also has the concept of shared-library partitions that any given
partition can link to, effectively giving access to the symbols there.
I think this is very comparable to shared libraries in Unix systems or
DLLs on Windows. It would be really nice if we eventually taught GDB to
recognize that two processes were using the same shared library and
thus internally loaded the symbol once.

-- 
Joel