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 13:50:00 -0000 Message-id: <3BB4E273.5020308@cygnus.com> References: <3BB4D843.A92818B9@cygnus.com> X-SW-Source: 2001-09/msg00435.html > + extern char * > + address_space_int_to_name (int space_flag) > + { > + if (space_flag & TYPE_FLAG_CODE_SPACE) > + return "code"; > + else if (space_flag & TYPE_FLAG_DATA_SPACE) > + return "data"; > + else > + return NULL; > + } > + Some thoughts on the internals. Should these spaces be flags or an enumeration? I don't think being able to specify space = (CODE | DATA) is meanginful. Haveing bit masks also puts a limitation on the number of spaces. Should a flag always be set (if not specified explicitly). For instance, a ``(*)()'' which implies the code space explicitly setting it as such? That will make some of the pointer to/from address code easier - just check the space - no need to test for func or method or .... I suspect that this is going to slowly affect other parts. At present there is a singe TARGET_PTR_BIT. Given different address spaces can have different sizes, that macro will be replaced by a more generic (target_space_ptr_bit (space). As you note, for the moment text/data are hardwired / pre-defined Eventually the target architecture will want an oportunity to define other spaces. That can follow. Andrew PS: I keep reading type_as_type as type as type :-)