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: Non-uniform address spaces


Michael Eager <eager@eagercon.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
  design.

- 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.


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