From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Jim Blandy Cc: Michael Snyder , gdb-patches@sources.redhat.com Subject: Re: [RFC/RFA] gdb extension for Harvard architectures Date: Wed, 10 Oct 2001 00:16:00 -0000 Message-id: <3BC3F5A3.8070005@cygnus.com> 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/msg00106.html I got curious and worked through this: > 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. I think that there are several things kicking around here. The syntax: The @ attribute being attached to the pointee rather than pointer. As you note, a syntax which attached the attribute to the pointer would lead to unnatural behavour in the C language. The representation within GDB. GDB's ``struct type'' needs to be modified so that it includes the space that a pointer is designating. Michael added it to the pointee so that it matched the syntax. As a consequence, both the syntax and the modified type system allow the representation of meaningless types such as ``@code struct { @data int i; }''. I suspect that ``struct type'' could be modified so that the address space attribute is stored with the pointer rather than pointee. However, I take it from Michael and your comments that this would lead to a cumbersom implementation - there is no longer a simple 1:1 mapping between the syntax and GDB's internal data structures. Andrew