[RFC/RFA] gdb extension for Harvard architectures

[Michael Snyder]

Andrew Cagney wrote:
> 
> > This is an extension to help with debugging on Harvard architectures
> > (machines with two or more address spaces, typically one for
> > instructions and one for data).  The idea here is to provide the user
> > with a mechanism for specifying the address space of a pointer or
> > a raw address (eg. to display the contents of code memory as opposed
> > to data memory, when the address alone is not enough to differentiate).
> >
> > Rather than provide extensions for specific commands such as print
> > and examine, it seemed more useful and general to provide an
> > extension to the syntax for type expressions.  Thus we can identify
> > a pointer to (say) code address space by using a pointer cast, and
> > that expression can be used in any command that accepts an expression.
> >
> >       (gdb) x /xb (@code short *) foo
> >       (gdb) print *(@data char *) 0x1000
> >       (gdb) set *(@code long long *) 0x1000 = 0
> >
> > The idea is that the modifiers "@code" and "@data" can be used
> > anywhere where it would be legal to use "const" or "volatile".
> > I've used the "@" character to remove the new keywords from the
> > user name space, but I'm open to discussion on that choice
> > ("$" might be another possibility).
> >
> > So, for instance, a (@code int *) would be a pointer to an int in
> > code space, while a (int * @code) would be a pointer in code space
> > to an int (presumably in data space).
> 
> The syntax feels long winded - which probably isn't unexpected.  It is
> playing around with a type system.  Shortened / abreviated forms are
> going to be useful.
> 
> I know Fche once suggested:
> 
>         x/i $code + 100
> 
> where $code designates a code base address.  I guess, using the above,
> $code would be syntatic sugar for ``(@code char *) 0'' giving ``(@code
> char *)0 + 100'' for the above.

That can be done as a future extension.  It's not precluded by this change, 
and in fact this change will facilitate that one ("$code" can be declared
as an array of (@code int)).

> --
> 
> Looking at the output and how it interacts.  I'll give several examples
> and possible outputs:
> 
>         (gdb) print (@data char *) 0x1000
> 
>         (@data char *) 0x1000
> or
> (char *) 0x1000
> 
>         (gdb) print ((@code *)()) 0x1000
> (I think)
> 
>         ((@code *)()) 0x1000
> or
> ((*)()) 0x1000
> 
> I think in each case it should display the latter - the ``@code''
> attribute is redundant information.  Only when the space conflicts with
> the values type should it be displayed.

My current patch includes only minimal changes to gdb's output.
Others can be added if the need is identified.

> 
> --
> 
> What about expressions.
> 
> Consider
>         (gdb) print (char *) function
> 
> should that return:
> 
>         (@data char *) ...
> or
> (@code char *) ...

What it actually returns is something like:

$1 = 0x1272 ""
Where 0x1272 is the data space form of the address of function, and
"" is the string that resides at that address (in data space).  
This is logical, because (char *) is a data-like type.