Re: [RFC/RFA] gdb extension for Harvard architectures

[Andrew Cagney <ac131313@cygnus.com>]

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