Re: [RFA] Add type support for Ada

["Paul N. Hilfinger" <hilfingr@otisco.mckusick.com>]

> It looks to me as if the string cleanup stuff is distinct from the
> fixed instance stuff.  These should be submitted as separate patches.

They definitely are logically separate changes.

> Is a `fixed instance' a feature of the language's type system itself?
> That is, is it something that an Ada programmer actually knows about?
> Or is it something used internally within GDB, or internally by some
> implementations of Ada?

It is not a language feature, but rather an optimization.  The original 
problem was that STABS and also GDB's internal type representation 
was not adequate for representing "dynamic" Ada types---i.e., those that,
unlike C types, have data-dependent sizes.  The scheme we hit on (in
retrospect perhaps not the best) was to encode a bunch of auxiliary 
information into our type names, and to introduce additional types 
carrying additional (encoded) information.  

When Ada evaluation routines discover that a quantity has an encoded
type, they know to compute a conventional, fixed-sized GDB type based on the
data, and to attach this type to the value they are producing.   

Unfortunately, the computations involved are expensive---involving type
lookups in some cases---and we don't want to repeat them unnecessarily.  
Hence the flag.

> Should base_type use the tortoise-and-hare algorithm to detect cycles?

An interesting suggestion.  However, there is at least one existing
place where GDB doesn't bother.  Compare with the following (non-Ada-
related) code from evaluate_subexp_standard in eval.c:

	  /* get targettype of elementtype */
	  while (TYPE_CODE (check_type) == TYPE_CODE_RANGE ||
		 TYPE_CODE (check_type) == TYPE_CODE_TYPEDEF)
	    check_type = TYPE_TARGET_TYPE (check_type);

> When it detects a direct cycle, should it really just return the type,
> or should that be an internal error?  When the base type of a range
> type is null, should that be an internal error?

Umm. Interesting questions.  As I recall, I had the impression that 
a self-referencing range type COULD occur legitimately, but given that was
4 years ago, my memory could be faulty.  I suspect these tests were simply
bullet-(or segfault)-proofing.  Replacing the NULL check at least with
an error would probably be a worthy experiment.

Paul