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

[Jim Blandy <jimb at zwingli dot cygnus dot com>]

Andrew Cagney <ac131313@cygnus.com> writes:
> Finally, there are the semantics of the operations.  Here I think we're 
> clearly disagreeing.  I'm arguing that an address is an address is an 
> address - it always designates the one location - unless explicitly 
> converted.  In the proposal it silently moves depending on what was 
> done.  The  pointer cast operator is being given certain semantics - I 
> think those semantics are not what the user expects.

In any C compiler, the expressions `(int *) &main' and `(int (*) ())
&argc' will also silently change the location referred to.  GDB is
simply evaluating the expressions the way the compiler would.

(BTW, these are also GDB's current semantics.  The proposal doesn't
introduce any new inconsistencies.)

What if GDB printed a warning when an operation switched a pointer
from one space to another?

  (gdb) print * (int *) &main
  Warning: cast converts pointer from code space to data space.
  Perhaps you should use (@code int *) instead.
  $2 = 42
  (gdb)

If the user spells out the space, GDB could keep its mouth shut:

  (gdb) print * (@data int *) &main
  $3 = 42
  (gdb)

> ``Note below'':
> 
> 
> The basic framework attached the segment information to the pointee 
> rather than pointer.  Was this an arbitrary decision or based on some 
> theoretical framework.

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.

> Since the pointee gets the attribute it is possible to construct things 
> like:
> 
> 	(@code struct { @data int i; @io unsigned char *@data c; } *)
> 
> was this the intent?  (I suspect it was: having a @data -> @io space 
> pointer sitting in code memory, while sick, is still plausable).

You can't have a struct living in code space with a member in data
space; a struct's members live in the same space as the struct itself.