Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Jim Blandy <jimb@codesourcery.com>
To: Michael Eager <eager@eagercon.com>
Cc: gdb@sources.redhat.com
Subject: Re: Non-uniform address spaces
Date: Tue, 26 Jun 2007 23:39:00 -0000	[thread overview]
Message-ID: <m3odj2p9p4.fsf@codesourcery.com> (raw)
In-Reply-To: <46819C43.7040506@eagercon.com> (Michael Eager's message of "Tue, 26 Jun 2007 16:07:47 -0700")


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.


      reply	other threads:[~2007-06-26 23:39 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-23 16:31 Michael Eager
2007-06-23 21:25 ` Daniel Jacobowitz
2007-06-23 21:47   ` Michael Eager
2007-06-23 23:09     ` Daniel Jacobowitz
2007-06-25 17:46     ` Jim Blandy
2007-06-25 18:08       ` Michael Eager
2007-06-25 19:05         ` Jim Blandy
2007-06-25 19:09           ` Daniel Jacobowitz
2007-06-25 20:04           ` Michael Eager
2007-06-25 22:23             ` Jim Blandy
2007-06-25 22:55               ` Michael Eager
2007-06-25 23:08                 ` basic gdb usage question Matt Funk
     [not found]                   ` <655C3D4066B7954481633935A40BB36F041415@ussunex02.svl.access-company.com>
2007-06-25 23:36                     ` Matt Funk
2007-06-26  1:25                       ` Michael Eager
2007-06-26  3:12                   ` Eli Zaretskii
2007-06-26 16:13                     ` Matt Funk
2007-06-27  3:29                       ` Eli Zaretskii
2007-06-26 16:56                 ` Non-uniform address spaces Jim Blandy
2007-06-26 17:22                   ` Michael Eager
2007-06-26 17:55                     ` Jim Blandy
2007-06-26 18:08                     ` Jim Blandy
2007-06-26 23:08                       ` Michael Eager
2007-06-26 23:39                         ` Jim Blandy [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3odj2p9p4.fsf@codesourcery.com \
    --to=jimb@codesourcery.com \
    --cc=eager@eagercon.com \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox