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

[Andrew Cagney <ac131313@cygnus.com>]

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

--

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.

--

What about expressions.

Consider
	(gdb) print (char *) function

should that return:

	(@data char *) ...
or 
(@code char *) ...





> The idea should be extendable to more address spaces (eg. if 
> there was an I/O space), and possibly also to segmented architectures.
> 
> Here's a somewhat preliminary (but buildable and working) patch:
> 
>