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

[Michael Snyder <msnyder@cygnus.com>]

Andrew Cagney wrote:
> 
> >> (gdb) print/x *(int*)foo
> >> 0xdeadbeef
> >
> >
> > An (int *) is by default a data pointer.
> > A function pointer is by default a code pointer.
> 
> As far as I know, the C language says nothing about the above (assuming
> foo is a function). 

Of course.  I was describing GDB's current behavior.

> It is an implementation defined pointer cast open
> to any interpretation.  All it defines are ``pointer from data to data
> space'' and ``pointer from data to code space''.  It doesn't even define
> foo+4, where foo is a function.
> 
> Any way, lets break down the proposal.
> 
> --
> 
> Firstly it is adding a mechanism that will allow GDB to represent
> pointers to / from / within any address space.

Well, technically, it is extending a mechanism that GDB already uses.
The current mechanism is that expressions that point to a data-like type
(scalar, struct, array-of-data-like type etc.) point to data space, and
expressions that point to functions point to code space.  My proposal
is giving the user the ability to override this default behavior.



> We absolutly need this.  And such a change can probably be dropped right
> in. However check note below.
> 
> --
> 
> Next we've got the syntax change - an attribute extension.  While querky
>   it doesn't worry me - if I'm understanding it correctly, it is
> possible to add syntatic sugar for common operations (such as references
> to code space) [see other e-mail]. (However do check note below :-)
> 
> --
>
> 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.

We should discuss in detail what the semantics currently are, 
vs. what the proposal would change them to.  I'm not sure we are
on the same page about either of those.

For instance, it's not true that currently "an address is an address".
Without my change, it is already possible to cast a function (code) address
into a data address.  An example that you gave earlier already does this:

	print *(int *) main

will give the value of the int residing in the data-space address
corresponding to the code-space address of main.  Currently it is 
not possible to type an expression that refers to the int residing
in the CODE-SPACE address of main.  My extension gives that ability.


> Per my previous comment, given a function foo.  I'd contend that the
> user is going to expect the expression:
> 
>         *(int*)foo
> 
> to print an integer at address foo and not at some other data address.

Perhaps -- but that's not what currently would happen.
We can probably have a long debate about what a user would expect.
But I point out that without my change, the user has no way to do
what you suggest, whereas with my change he does.


> BTW, regarding ``(int *)'' is always ``(@data int *@data)'' that is
> true.  Rember though that the above is really:
> 
>         cast ((int*), (@code *@data))
> 
> and as far as I know, this operation isn't defined by C? 

I'm sure that's true.

> It is free to
> apply arbitrary transformations that might include:
> 
>         (@data int *@data)
> or
> (@code int *@data)
> 
> Any way, if GDB is going to have an address changes model (I consider
> this user broken) then, at a minimum, it should warn the user that an
> address space change has been applied to their apparently simple address
> expression.

Perhaps.

> 
> --
> 
> ``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.

It seems to me to make the most sense (and Jim Blandy seems to agree).
It gives you the ability to construct arbitrary combinations, such as
a data-space pointer to a data-space pointer to a code-space int.


> 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? 

Not explicitly, no -- but along with the power to construct arbitrary
expressions comes the ability to construct expressions that don't make
much sense.  Debuggers sometimes have more power than you would have
in the native language (for instance, you can modify the private data
of a C++ class).  With this power comes the ability to shoot yourself
in the foot -- users have to know this.  The debugger doesn't warn you
when you modify the private data of a base class.

To show a simple example, the parser that I've submitted will accept
the expression "(@code @code int)".  That doesn't make terribly much
sense, but it's harmless.  It will also probably accept the expression
"(@code @data int)".  That's more serious, and should probably be an error.

> (I suspect it was: having a @data -> @io space
> pointer sitting in code memory, while sick, is still plausable).
> 
> Andrew