[RFH/RFC] Support for ARINC 653 partitions in GDB...

[Joel Brobecker <brobecker at adacore dot com>]

Hello,

Jerome and I are currently working on cleaning up our patch to provide
support for VxWorks in GDB. This includes support for VxWorks 5.x (x>=4),
VxWorks 653 (I forgot the official name, now), and VxWorks 6.x.
For the purpose of this exercise, we treat VxWorks 5.x as a degenerated
version of VxWorks 653 because it only has a single (kernel) partition.

One of the iffy areas of the code is how we deal with partitions, and
I am not sure how to fit this concept into GDB. I was initially thinking
of looking at program spaces and address spaces, but it looks like
program-spaces and partitions might be different concepts...

In a nutshell, A system is made of partitions. In principle, each partition
is running independently of the others. In particular, address spaces
(code and data) are completely segregated - each having their own
virtual address space. There are special partitions, however, to make
things even more fun:
  - The kernel partition: all symbols visible and accessible from
    all partition;
  - Shared library partitions: A selected list of routines are accessible
    to the partitions that are setup to use that partition.

We always need to be aware of partitions, because symbols are always
relative to their associated partition. For instance, when inserting
a breakpoint, the breakpoint address is relevant to the partition
inside which the symbol is defined. The same address used in a different
partition usually refers to an unrelated entity.

Initially, I was thinking of designing this system around 1 partition
is one program space. But that would not work in the situation where
we debug the entire system because we'd be in a situation where we
debug one process (the system) which spans across multiple partitions
(we call this debugging mode "system-mode").

So, at this point, I don't see the use of program spaces would be
the right concept to use in order to fit the partitions in; I think
that the cleanest thing to do would be to add yet another layer
(partition) which contains 1 or more program spaces?

The other concept I'm a little worried about is kernel and shared
partitions.  Basically, the objfiles obtained from reading the debug
info in those partitions need to be shared between the other
partitions (aka "application" partitions).  I don't know if this is
achievable with the current program-space model.

Any thoughts and/or suggestion on that? Pedro, does the idea of adding
the concept of partitions seem about right to you, or is there a way
to enhance the current program-space/process/address-space model?

Thank you,
-- 
Joel