This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Add support for VxWorks (v3)


On Friday 04 March 2011 06:21:40, Joel Brobecker wrote:
> I haven't answered Tom's question regarding "partitions" vs "program
> and address spaces". I haven't completely designed what should be the
> proper implementation for partitions. But I think it will most likely
> use those concept. But it'll need some extensions, which I need to
> formalize, when I have time.

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?

That is, are multiple partitions considered part of
the same program/inferior, or should each partition be
mapped to its own inferior?  The descriptions I've
seen seem to say that each partition holds its own
set of program and symbols, so my reaction is "why's that
different from having multiple inferiors, each grouping the
threads that are running in a given partition".

OTOH, I do think there's space for something like
partitions in gdb --- e.g., on cell, I think the desire
would be for a single inferior to group several program
spaces --- one for the ppc side, and another or
8 others (don't have a clear idea on that) for
the spu programs.  But in the cell case, it's clear
to me that the cell's spu partitions are part of the
larger inferior.

I haven't understood if WxWorks' case is like cell's
or simply this new concept is working around something
that older gdb's did not understand (multi-inferiors).

-- 
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]