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

[Michael Snyder <msnyder at cygnus dot com>]

Andrew Cagney wrote:
> 
> > What about expressions.
> >
> > Consider
> >     (gdb) print (char *) function
> >
> > should that return:
> >
> >     (@data char *) ...
> > or (@code char *) ...
> 
> Oops, pressed the wrong button ...
> 
> My question here is, should the address space be propogated through a
> type conversion (when it isn't explicitly specified)?
> 
> The user might have the expression:
> 
>         x/i function
> 
> and then enter
> 
>         x/w function
> 
> Both will examine the same memory location. 

Correct.  The code-space memory location.

> The user could then try to
> manipulate that data with:
> 
>         print *(int*)function
> 
> however, depending on the interpretation of the expression (I don't
> believe ISO C defines the semantics of this)

Correct (AFAIK).

> you could end up printing a
> value from a completly different address space.

The above operation works even without my change.  Since (int*) 
is interpreted as a naturally "data-like" expression, the above
will give you the int that lives in the data-space address corresponding
to the code-space address of "function".

What my change _adds_ to this picture is the ability to say

	print *(@code int *) function

which will print the int that resides in the CODE-SPACE address
corresponding to the address of "function".  This is something
that you cannot do without my change.

> Would it be better if the cast operator, by default, preserved the
> address space of the pointer being cast?

That would be _more_ of a change than my proposed change.
As such, I think that that change can be discussed independently
of my proposed change.  The current behavior of GDB (without my
change) is that a cast to a data-like type always refers to 
data space, and a cast to a function-like type always refers
to code space.