Re: debug/1621: Debugging with complex numbers

[Jim Wilson <wilson at redhat dot com>]

>I recommend emitting just the generic NF_COMPLEX and NF_FLOATING (?)
>for any of the unknown types.

NF_COMPLEX is supposed to be IEEE single complex.  There is no generic
value for complex types.  However, I do see your point, since we have the
type size anyways, we don't really need to distinguish between the different
complex types for IEEE FP targets.

There is a problem if we want to distinguish between IEEE and non-IEEE FP,
in which case the type size is not enough.  For instance, most RISC targets
use a 128-bit IEEE double-extended type.  However, some powerpc targets use
a 128-bit non-IEEE IBM pair-of-doubles type.  We can distinguish between these
two only if we have a special NF_* value for the IBM pair-of-doubles type.
Or alternatively, gdb just has to know that some targets use a non-IEEE long
double type.  This is different problem from the one we are trying to fix
though, and can be postponed for now.

>First of all, for floating point types we could just continue to use
>'r'.  It's not problematic in that case.  On the other hand consistency
>is nice.

My patch continues to use 'r' for floating point types for now.  I didn't
want to break backwards compatibility for other stabs targets.  'R' will
presumably only work on the Sun debugger and gdb.  It is OK to use 'R' for
complex because it is an GNU C extension to ISO C90, so users can't expect
old debuggers to handle it correctly.

I will modify my patch to use NF_COMPLEX and NF_SINGLE as generic FP type
descriptors and add appropriate comments about what we are doing in order
to fix GCC PR debug/1621.

Jim