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
I got curious and worked through this:
> I think the following rule is worth preserving:
>
> - If an expression E has some type T, then &E has type T *.
>
> This is a fundamental operation, and choosing the wrong behavior here
> will inevitably cause troubles elsewhere, too.
>
> Suppose you attach the qualifier to the pointer, and not the pointee.
> That is, `@code' may only be applied to pointer types, and it means
> that the pointer points to something in code space.
>
> Now suppose that `q' is an int living in code space. Since
> qualifiers apply to pointers only, q's type must be simply `int'.
> You'd like `&q' to have the type `int * @code', but the `&' rule
> above requires q's type must be simply `int'. So you have to
> break the `&' rule, or get stupid behavior.
>
> Also, there isn't any nice, compact way to describe what q is.
> The best you can say is, "q is an int in code space," as I did
> above.
>
> Suppose, on the other hand, that you attach a space qualifier to an
> object, indicating that it lives in that space. That is, `@code' may
> be applied to any type, and it means the object itself lives in code
> space.
>
> Suppose again that `q' is an int living in code space. Since
> qualifiers apply to objects, q's type must be `@code int'. As
> above, you'd like `&q' to have type `@code int *'. (This is the
> same type as above --- pointer to int in code space --- just
> written according to the new syntax) And this is in fact the type
> the `&' rule requires. All is well.
>
> Also, there is a nice way to describe q. You can simply say, "q
> is a @code int", or "@code int q".
>
> So the latter is what Michael proposed.
I think that there are several things kicking around here.
The syntax:
The @<region> attribute being attached to the pointee rather than
pointer. As you note, a syntax which attached the attribute to the
pointer would lead to unnatural behavour in the C language.
The representation within GDB.
GDB's ``struct type'' needs to be modified so that it includes the
space that a pointer is designating. Michael added it to the pointee so
that it matched the syntax. As a consequence, both the syntax and the
modified type system allow the representation of meaningless types such
as ``@code struct { @data int i; }''.
I suspect that ``struct type'' could be modified so that the address
space attribute is stored with the pointer rather than pointee.
However, I take it from Michael and your comments that this would lead
to a cumbersom implementation - there is no longer a simple 1:1 mapping
between the syntax and GDB's internal data structures.
Andrew