This is the mail archive of the
mailing list for the GDB project.
Re: Non-uniform address spaces
Michael Eager <email@example.com> writes:
> Yes, contributing to public sources is a goal.
Okay, that's great to hear.
> There are always factors which complicate this.
> - Working in different versions of GDB, with the need to port
> modifications from one version to another. There have been
> many changes in GDB which make code non-portable between
> different versions.
> - An interest in making minimal changes to solve a problem
> rather than engage in a major redesign effort.
> I'm helping the folks who are developing the UPC support for GDB.
> The sources are available on-line. I understand that they have an
> interest in submitting patches to support UPC when the code is a
> bit more stable. There's support in DWARF for UPC features, but
> the UPC language extensions have not yet been incorporated into
> the current version of GCC.
Right. Well, speaking generally, then:
- Some of what you're doing seems to resemble multi-process debugging.
Ulrich and Markus have been working on stuff for the Cell processor
which I think is similar, in that it involves a single GDB
addressing a number of separate address spaces. So if that work
turns out the way I think it will, GDB trunk will be a more
hospitable place for work like this.
- UPC shared arrays seem to have subscripting rules that differ from
those of standard C. It's fine to go ahead and change things like
value_subscript to handle these; those functions bear the
responsibility of supporting multiple languages in the current
- As I've said, I recommend using CORE_ADDR to represent global
addresses only. The target may have other kinds of addresses; those
should be promoted to CORE_ADDRs for use within GDB. I'd expect
POINTER_TO_ADDRESS and ADDRESS_TO_POINTER to be the places this
happens, but you may find that you want to add a new
FRAME_POINTER_TO_ADDRESS method, so that you can use information
from a value's execution context to construct the global address.