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

Andrew Cagney
2001-10-02T16:58:00Z

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