This is the mail archive of the gdb@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: Address spaces


Ulrich Weigand wrote:
Stan Shebs wrote:
Doug Evans wrote:
It would be useful to have proper address spaces for non-multi-process
situations too. At the moment all one can do is hack in bits to
unused parts of the address (assuming such bits are available ...).
[I'm sure this isn't news. Just saying there are multiple reasons for
addresses being more than just the CORE_ADDR of today, and if we solve
one, let's at least consider the others too.]
Do you have some specific ideas in mind? Because I was assuming (and this is good to be aware of) that there would not be more than one address space associated with a process. (Instantly split I/D targets a la D10V come to mind, although that was handled by distinguishing pointers from addresses.)

Cell/B.E. applications have multiple address spaces per process -- the main PowerPC address space (that is also accessible from the SPEs via DMA operations) plus a separate local store address space for each SPE context that is active in the process.

I'm currently using bit hacks to map all these address spaces into a
single CORE_ADDR space -- this is working OK for now, but it would
seem nicer to integrate this into a general notion of address spaces ...
Is this code in the GDB sources now? I'm not seeing anything obvious. But I'm guessing you mean that there can be a main() for the PPE and a main() for each SPE, and that they can all be literally at 0x12480, but since GDB wouldn't like that you have to do trickery in the target before anything is delivered to GDB?

The possibility of overlapping address spaces makes my head hurt a little. :-)

Stan


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