Re: Add support for VxWorks (v3)

[Pedro Alves <pedro at codesourcery dot com>]

On Friday 04 March 2011 10:04:34, Joel Brobecker wrote:
> > I haven't really looked at the code yet, but, the question
> > I think should be answered most importantly, is: do you
> > really need partitions at all?
> 
> Unfortunately, you do. The most common case is when you are debugging
> in system mode.  This essentially means debugging the entire system,
> and therefore multiple partitions. 

Not sure I understand the use case completely.

1) Could map into a single inferior and then "info sharedlibrary"
lists all partitions?  What is it in the use case that makes
this not viable?

or,

2) Could map each partition into an inferior?  What is
it in the use case that makes this not viable?

Again, note I'm not saying there's no space for something like
partitions, but if there is, I'd much rather it was for the
right reasons, and I'd like to understand what does it bring
that the current model doesn't support.

> Another use case is is when
> debugging a task that runs some code provided by a shared partition.
> It's a little bit like shared libraries on traditional OSes.  In that
> case, you're effectively debugging over several partitions at the same
> time.

So that task would be mapped to a running inferior, and the
shared partition would appear under shared libraries?

> I should also repeat that the partition-switching implementation has
> been stubbed out (meaning not contributed yet). The reason for that
> is that it makes some assumptions about how core GDB accesses its
> objfiles. I was under quite a bit of pressure when I implemented this,
> and the good news is that it's localized, and never broke in the years
> since I wrote the code. I'm keeping my fingers crossed.  But what it
> does is rebuild GDB's objfile list at each partition switch. This
> allows us to give the user the same visibility rules as the code
> running loaded in that partition.

If we end up with partitions, note that the "program space" entity
was designed specifically for this.  From your description, the
partition's symbols are a natural fit for a "program space".
I kept the "address space" object separate from the "program space"
exactly for cases like these, where you have several
distinct programs (program spaces / partitions) running under
the same address space.  You shouldn need objfile list
swapping hacks anymore.

> I have some ideas of how I would like to integrate that concept
> in GDB. There are two issues: (1) we need one list of objfiles
> per partition - that should be relatively easy to deal with;
> (2) we have some partitions that are a little special: (2a)
> the "kernel" partition, which is a partition accessible from
> all other partitions; (2b) shared partitions, which can be
> accessible from other partitions, provided that the shared
> partition is in the "link path" of the client partition (it's
> an ordered list of shared partitions). I think we can deal with
> the "kernel" partition as being an implicit shared partition -
> that would be dealt with at the target level.  But we will need
> to teach the objfile walking about link paths (not very hard,
> I expect).

-- 
Pedro Alves