From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Blandy To: Andrew Cagney Cc: Michael Snyder , Jim Blandy , gdb-patches@sources.redhat.com Subject: Re: [RFC/RFA] gdb extension for Harvard architectures Date: Wed, 03 Oct 2001 10:10:00 -0000 Message-id: References: <3BB4D843.A92818B9@cygnus.com> <3BB512A9.6050801@cygnus.com> <3BB5195F.6050603@cygnus.com> <3BBA2DC9.5060500@cygnus.com> <3BBA3B03.B864ABE0@cygnus.com> <3BBA54AE.3080104@cygnus.com> X-SW-Source: 2001-10/msg00046.html Andrew Cagney writes: > 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. In any C compiler, the expressions `(int *) &main' and `(int (*) ()) &argc' will also silently change the location referred to. GDB is simply evaluating the expressions the way the compiler would. (BTW, these are also GDB's current semantics. The proposal doesn't introduce any new inconsistencies.) What if GDB printed a warning when an operation switched a pointer from one space to another? (gdb) print * (int *) &main Warning: cast converts pointer from code space to data space. Perhaps you should use (@code int *) instead. $2 = 42 (gdb) If the user spells out the space, GDB could keep its mouth shut: (gdb) print * (@data int *) &main $3 = 42 (gdb) > ``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. I think the following rule is worth preserving: - If an expression E has some type T, then &E has type T *. This is a fundamental operation, and choosing the wrong behavior here will inevitably cause troubles elsewhere, too. Suppose you attach the qualifier to the pointer, and not the pointee. That is, `@code' may only be applied to pointer types, and it means that the pointer points to something in code space. Now suppose that `q' is an int living in code space. Since qualifiers apply to pointers only, q's type must be simply `int'. You'd like `&q' to have the type `int * @code', but the `&' rule above requires q's type must be simply `int'. So you have to break the `&' rule, or get stupid behavior. Also, there isn't any nice, compact way to describe what q is. The best you can say is, "q is an int in code space," as I did above. Suppose, on the other hand, that you attach a space qualifier to an object, indicating that it lives in that space. That is, `@code' may be applied to any type, and it means the object itself lives in code space. Suppose again that `q' is an int living in code space. Since qualifiers apply to objects, q's type must be `@code int'. As above, you'd like `&q' to have type `@code int *'. (This is the same type as above --- pointer to int in code space --- just written according to the new syntax) And this is in fact the type the `&' rule requires. All is well. Also, there is a nice way to describe q. You can simply say, "q is a @code int", or "@code int q". So the latter is what Michael proposed. > 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). You can't have a struct living in code space with a member in data space; a struct's members live in the same space as the struct itself.