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

[Andrew Cagney <ac131313@cygnus.com>]

>> (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).  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.

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.

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.

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

--

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

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

Andrew