From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Michael Snyder Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC/RFA] gdb extension for Harvard architectures Date: Fri, 28 Sep 2001 17:15:00 -0000 Message-id: <3BB512A9.6050801@cygnus.com> References: <3BB4D843.A92818B9@cygnus.com> X-SW-Source: 2001-09/msg00446.html > 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: > >