The i387 floting point unit handles 'long double' float type 
with 80 bits, but GCC and most compilers pretend that this 
type is 96 bit long (mainly for alignment purposes).

  Nevertheless, at least Free Pascal does use 80 bit size for this type.
As GDB does not recognize this size, the stabs output has been 
twisted to simulate 96 bit 'long double' type, so that normal
'extended' (the Free Pascal name of this float type) variables
can be inspected correctly.
 Nevertheless, this leads to a very bad situation when we try to inspect 
Free Pascal arrays of extended, because GDB searches the second element
at offset 12 (in bytes) relative to the first address, when it is in fact at offset 10.
To avoid GDB from outputing non-sense, I added 
an explicit size specific to the stabs output, this leads 
CVS head GDB to claim about the fact that it does not know
how to handle 10 byte long floats.

The following patch add a new variable to the gdbarch vector:
long_double_bit_alternate
which can be used to accept a second size for 
the same type 'long double'.
The default value is 0, which renders it useless unless 
explicitly set. 
It is then set to 80 bit in i386-tdep.c

The addition of long_double_bit_alternate variable leads to 
the creation of the new macro
TARGET_LONG_DOUBLE_BIT_ALTERNATE
that is used in function floatformat_from_length
to return the same type as for TARGET_LONG_DOUBLE_BIT.

This simple patch allows to correctly display 
arrays of extended in Free Pascal compiled code.
I don't know really if this is used in other compilers,
but I suspect that it could be also used in 
x86-64-tdep.c or ia64-tdep.c.




ChangeLog entry:

2003-02-17  Pierre Muller  <muller@ics.u-strasbg.fr>

	* gdbarch.sh: Add long_double_bit_alternate variable.
	* gdbarch.h, gdbarch.c: Re-genarate.
	* doublest.c (floatformat_from_length): Accept also
	long_double_bit_alternate length for 'long double' type.
	* i386-tdep.c (i386_gdbarch_init ): Set long_double_bit_alternate to 80.