From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Michael Snyder , Jim Blandy Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC/RFA] gdb extension for Harvard architectures Date: Tue, 02 Oct 2001 16:58:00 -0000 Message-id: <3BBA54AE.3080104@cygnus.com> References: <3BB4D843.A92818B9@cygnus.com> <3BB512A9.6050801@cygnus.com> <3BB5195F.6050603@cygnus.com> <3BBA2DC9.5060500@cygnus.com> <3BBA3B03.B864ABE0@cygnus.com> X-SW-Source: 2001-10/msg00041.html >> (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