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
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: [RFC/RFA] gdb extension for Harvard architectures
- From: Michael Snyder <msnyder at cygnus dot com>
- Date: Wed, 03 Oct 2001 10:54:08 -0700
- CC: gdb-patches at sources dot redhat dot com
- Organization: Red Hat
- References: <3BB4D843.A92818B9@cygnus.com> <3BB512A9.6050801@cygnus.com> <3BB5195F.6050603@cygnus.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.