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: Tue, 09 Oct 2001 23:34:00 -0000 Message-id: <3BC3EBAC.50609@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/msg00105.html >> 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. The syntax change will allow it even though it is probably meaningless (Mind you, i've this fuzzy memory of a language (ada?, VAX pascal?) allowing you to specify sparse structures.) With regard to a @data->@io pointer. That is probably wrong. Pointers, which are typically implemented as address registers (not to be confused with GDB's core addr), have a fixed size for a given address space. Andrew