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

Michael Snyder
2001-10-03T10:55:00Z

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.