This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFC/RFA] gdb extension for Harvard architectures
- To: Michael Snyder <msnyder at cygnus dot com>
- Subject: Re: [RFC/RFA] gdb extension for Harvard architectures
- From: Daniel Jacobowitz <drow at mvista dot com>
- Date: Wed, 3 Oct 2001 14:06:39 -0400
- Cc: Andrew Cagney <ac131313 at cygnus dot com>, gdb-patches at sources dot redhat dot com
- References: <3BB4D843.A92818B9@cygnus.com> <3BB4E273.5020308@cygnus.com> <3BBB4D90.AE2B5AEE@cygnus.com>
On Wed, Oct 03, 2001 at 10:40:32AM -0700, Michael Snyder wrote:
> Andrew Cagney wrote:
> >
> > > + extern char *
> > > + address_space_int_to_name (int space_flag)
> > > + {
> > > + if (space_flag & TYPE_FLAG_CODE_SPACE)
> > > + return "code";
> > > + else if (space_flag & TYPE_FLAG_DATA_SPACE)
> > > + return "data";
> > > + else
> > > + return NULL;
> > > + }
> > > +
> >
> > Some thoughts on the internals.
> >
> > Should these spaces be flags or an enumeration? I don't think being
> > able to specify space = (CODE | DATA) is meanginful. Haveing bit masks
> > also puts a limitation on the number of spaces.
>
> Yes, but it's a generous limitation (there are 20 more bits available).
> I'll go either way -- the trade-off is that if we don't use the "flags"
> field, we have to add a new field to the (struct type) data structure.
May I suggest:
if ((space_flag & TYPE_FLAG_SPACE_MASK) == TYPE_FLAG_CODE_SPACE)
I'd prefer to preserve the knowledge that an object is in only one
space.
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer