While testing cplusfuncs.exp on ARM/NetBSD (a.out) with gcc-3 current, gdb 
is getting stuck in an infinite loop in gdbtypes.c:make_cv_type and I'm 
trying to work out what this is supposed to do.  The scenario I'm seeing 
is that the type ring has become corrupted as follows along the 
TYPE_CV_TYPE chain

          type
	    |
            V
	  var1<----+
            |      |
            +------+

Given that this is supposed to be a loop, it's clearly bogus.

The reason for this seems to be that dbx_lookup_type is returning the 
address of var1 as the place to put the modified type; ie it's asking 
make_cv_type to modify an existing type variant.  I'm not entirely sure 
that this is correct, but it may be that this is how the stabs reader 
creates a type -- ie it creates it, and then modifies it as it reads in 
more attributes.

There are several issues with make_cv_type:

1) Why is the top loop not executed at all when the cv loop has no 
variants?  It could be that we want the base type to be returned, and we 
never can as the code is written (we end up creating an identical copy).

2) The chain updating at the end of the function is written in a bizarre 
way, in that it assumes we will be inserting in the last entry before the 
base type.  While this has so-far been the case (because of the way the 
top loop was written), it doesn't seem like the normal way to express such 
an insertion operation (it implies that we could be dropping part of the 
chain).

3) There's no support for updating an existing entry in the loop.

Adding the patch below solves that problem, but we then segfaults on 
another type because the TYPE_CV_TYPE loop has been smashed by the memset 
in make_pointer_type.  This appears to happen at several places in that 
file, and it seems to me that we really need a function realloc_type() 
that is analogous to alloc_type, but recycles the type in a sensible 
manner.  I've written such a function as well.

Of course, it could be that the stabs reader is doing something completely 
bogus by passing the addresses of existing types into the gdbtypes code, 
in which case that will have to be rewritten to prevent this; but it 
doesn't seem like that was the intention.

R.

<date>  Richard Earnshaw  (rearnsha@arm.com)

	* gdbtypes.c (make_cv_type): Handle being asked to modify an 
	existing type in the chain.
	(realloc_type): Cleanly recyle memory for a type.
	(make_pointer_type): Use realloc_type to recycle an existing type.
	(make_reference_type): Likewise.
	(make_function_type): Likewise.
	(smash_to_member_type): Likewise.
	(smash_to_method_type): Likewise.