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: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Fri, 28 Sep 2001 16:49:55 -0400
- Cc: gdb-patches at sources dot redhat dot com
- References: <3BB4D843.A92818B9@cygnus.com>
> + 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.
Should a flag always be set (if not specified explicitly). For
instance, a ``(*)()'' which implies the code space explicitly setting it
as such? That will make some of the pointer to/from address code easier
- just check the space - no need to test for func or method or ....
I suspect that this is going to slowly affect other parts. At present
there is a singe TARGET_PTR_BIT. Given different address spaces can
have different sizes, that macro will be replaced by a more generic
(target_space_ptr_bit (space).
As you note, for the moment text/data are hardwired / pre-defined
Eventually the target architecture will want an oportunity to define
other spaces. That can follow.
Andrew
PS: I keep reading type_as_type as type as type :-)