* Re: ARM floating point regs regression
2002-01-23 3:45 ARM floating point regs regression Richard Earnshaw
@ 2002-01-22 9:26 ` Andrew Cagney
2002-01-22 9:30 ` Richard Earnshaw
0 siblings, 1 reply; 5+ messages in thread
From: Andrew Cagney @ 2002-01-22 9:26 UTC (permalink / raw)
To: Richard.Earnshaw; +Cc: gdb
> Program received signal SIGSEGV, Segmentation fault.
> floatformat_is_nan (fmt=0x0, val=0xefbfcc14 "")
> at /nfs/sun18//work/rearnsha/gnusrc/src/gdb/src/gdb/doublest.c:457
> 457 if (! fmt->exp_nan)
> (top-gdb) p fmt
> $1 = (struct floatformat *) 0x0
> (top-gdb) where
> #0 floatformat_is_nan (fmt=0x0, val=0xefbfcc14 "")
> at /nfs/sun18//work/rearnsha/gnusrc/src/gdb/src/gdb/doublest.c:457
> #1 0x0007ba4c in c_val_print (type=0x1c0d80, valaddr=0xefbfcc14 "",
> embedded_offset=0, address=0, stream=0x1ae000, format=0, deref_ref=1,
> recurse=0, pretty=Val_no_prettyprint)
> at /nfs/sun18//work/rearnsha/gnusrc/src/gdb/src/gdb/c-valprint.c:439
> #2 0x00016400 in val_print (type=0x1c0d80, valaddr=0xefbfcc14 "",
> embedded_offset=0, address=0, stream=0x1ae000, format=0, deref_ref=1,
> recurse=0, pretty=Val_pretty_default)
> ...
>
> Breakpoint 3, print_floating (valaddr=0xefbfcc14 "", type=0x1c0d80,
> stream=0x0)
> at /nfs/sun18//work/rearnsha/gnusrc/src/gdb/src/gdb/valprint.c:551
> 551 const struct floatformat *fmt = floatformat_from_type (type);
> (top-gdb) p type
> $2 = (struct type *) 0x1c0d80
> (top-gdb) p *type
> $3 = {code = TYPE_CODE_FLT,
> name = 0x527c8 "builtin_type_arm_ext_littlebyte_bigword", tag_name =
> 0x0,
> length = 12, upper_bound_type = 0, lower_bound_type = 0, objfile = 0x0,
> target_type = 0x0, pointer_type = 0x0, reference_type = 0x0,
> cv_type = 0x1c0d80, as_type = 0x1c0d80, flags = 0, nfields = 0,
> fields = 0x0, vptr_basetype = 0x0, vptr_fieldno = -1, type_specific = {
> arg_types = 0x0, cplus_stuff = 0x0, floatformat = 0x0}}
Hmm, type->type_specific.floatformat shouldn't be NULL here. Checking
gdbtypes.c:
builtin_type_i387_ext =
init_type (TYPE_CODE_FLT, floatformat_i387_ext.totalsize / 8,
0, "builtin_type_i387_ext", NULL);
TYPE_FLOATFORMAT (builtin_type_i387_ext) = &floatformat_i387_ext;
which is good, but:
builtin_type_arm_ext_littlebyte_bigword =
init_type (TYPE_CODE_FLT,
floatformat_arm_ext_littlebyte_bigword.totalsize / 8,
0, "builtin_type_arm_ext_littlebyte_bigword", NULL);
is bad.
I don't know how but almost all the lines initializing TYPE_FLOATFORMAT
were lost.
Andrew
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ARM floating point regs regression
2002-01-22 9:26 ` Andrew Cagney
@ 2002-01-22 9:30 ` Richard Earnshaw
2002-01-22 10:01 ` Andrew Cagney
0 siblings, 1 reply; 5+ messages in thread
From: Richard Earnshaw @ 2002-01-22 9:30 UTC (permalink / raw)
To: Andrew Cagney; +Cc: Richard.Earnshaw, gdb
> Hmm, type->type_specific.floatformat shouldn't be NULL here. Checking
> gdbtypes.c:
>
> builtin_type_i387_ext =
> init_type (TYPE_CODE_FLT, floatformat_i387_ext.totalsize / 8,
> 0, "builtin_type_i387_ext", NULL);
> TYPE_FLOATFORMAT (builtin_type_i387_ext) = &floatformat_i387_ext;
>
> which is good, but:
>
> builtin_type_arm_ext_littlebyte_bigword =
> init_type (TYPE_CODE_FLT,
> floatformat_arm_ext_littlebyte_bigword.totalsize / 8,
> 0, "builtin_type_arm_ext_littlebyte_bigword", NULL);
>
> is bad.
>
> I don't know how but almost all the lines initializing TYPE_FLOATFORMAT
> were lost.
>
Hmm, I think I understand why it is failing.
Although the FPA has an extended float format (which is used for stacking
regs across function calls), this type isn't used for "long double". So I
suspect the initialization code in gdbtypes.c is not setting it up
correctly for this case.
R.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ARM floating point regs regression
2002-01-22 9:30 ` Richard Earnshaw
@ 2002-01-22 10:01 ` Andrew Cagney
2002-01-22 10:10 ` Richard Earnshaw
0 siblings, 1 reply; 5+ messages in thread
From: Andrew Cagney @ 2002-01-22 10:01 UTC (permalink / raw)
To: Richard.Earnshaw; +Cc: gdb
[-- Attachment #1: Type: text/plain, Size: 1054 bytes --]
> I don't know how but almost all the lines initializing TYPE_FLOATFORMAT
>> were lost.
>>
(try the attached, if it works, I'll add a few extra assertions so that the coredump can't occure).
>
>
> Hmm, I think I understand why it is failing.
>
> Although the FPA has an extended float format (which is used for stacking
> regs across function calls), this type isn't used for "long double". So I
> suspect the initialization code in gdbtypes.c is not setting it up
> correctly for this case.
It shouldn't have got that far. the FPA extended float should have
TYPE_FLOATFORMAT set so that GDB can correctly and directly manipulate
the floating point value - no conversions being needed. The above
should stop this. Only as a last resort should gdb be trying to map a
floating point type onto one of float, double or long double.
BTW, it didn't work this way in the past. In the ``good old days'' GDB
would convert hardware floating point formats into float, double, or
long double (no matter how lossy that process was).
Andrew
[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 4742 bytes --]
2002-01-22 Andrew Cagney <ac131313@redhat.com>
* gdbtypes.c (_initialize_gdbtypes): Initialize TYPE_FLOATFORMAT
for builtin_type_ieee_single_little, builtin_type_ieee_double_big,
builtin_type_ieee_double_little,
builtin_type_ieee_double_littlebyte_bigword,
builtin_type_m68881_ext, builtin_type_i960_ext,
builtin_type_m88110_ext, builtin_type_m88110_harris_ext,
builtin_type_arm_ext_big, builtin_type_arm_ext_littlebyte_bigword,
builtin_type_ia64_spill_big, builtin_type_ia64_spill_little and
builtin_type_ia64_quad_big, builtin_type_ia64_quad_little.
Index: gdbtypes.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbtypes.c,v
retrieving revision 1.37
diff -p -r1.37 gdbtypes.c
*** gdbtypes.c 2002/01/20 19:42:04 1.37
--- gdbtypes.c 2002/01/22 17:54:14
*************** _initialize_gdbtypes (void)
*** 3328,3342 ****
--- 3328,3346 ----
builtin_type_ieee_single_little =
init_type (TYPE_CODE_FLT, floatformat_ieee_single_little.totalsize / 8,
0, "builtin_type_ieee_single_little", NULL);
+ TYPE_FLOATFORMAT (builtin_type_ieee_single_little) = &floatformat_ieee_single_little;
builtin_type_ieee_double_big =
init_type (TYPE_CODE_FLT, floatformat_ieee_double_big.totalsize / 8,
0, "builtin_type_ieee_double_big", NULL);
+ TYPE_FLOATFORMAT (builtin_type_ieee_double_big) = &floatformat_ieee_double_big;
builtin_type_ieee_double_little =
init_type (TYPE_CODE_FLT, floatformat_ieee_double_little.totalsize / 8,
0, "builtin_type_ieee_double_little", NULL);
+ TYPE_FLOATFORMAT (builtin_type_ieee_double_little) = &floatformat_ieee_double_little;
builtin_type_ieee_double_littlebyte_bigword =
init_type (TYPE_CODE_FLT, floatformat_ieee_double_littlebyte_bigword.totalsize / 8,
0, "builtin_type_ieee_double_littlebyte_bigword", NULL);
+ TYPE_FLOATFORMAT (builtin_type_ieee_double_littlebyte_bigword) = &floatformat_ieee_double_littlebyte_bigword;
builtin_type_i387_ext =
init_type (TYPE_CODE_FLT, floatformat_i387_ext.totalsize / 8,
0, "builtin_type_i387_ext", NULL);
*************** _initialize_gdbtypes (void)
*** 3344,3376 ****
--- 3348,3390 ----
builtin_type_m68881_ext =
init_type (TYPE_CODE_FLT, floatformat_m68881_ext.totalsize / 8,
0, "builtin_type_m68881_ext", NULL);
+ TYPE_FLOATFORMAT (builtin_type_m68881_ext) = &floatformat_m68881_ext;
builtin_type_i960_ext =
init_type (TYPE_CODE_FLT, floatformat_i960_ext.totalsize / 8,
0, "builtin_type_i960_ext", NULL);
+ TYPE_FLOATFORMAT (builtin_type_i960_ext) = &floatformat_i960_ext;
builtin_type_m88110_ext =
init_type (TYPE_CODE_FLT, floatformat_m88110_ext.totalsize / 8,
0, "builtin_type_m88110_ext", NULL);
+ TYPE_FLOATFORMAT (builtin_type_m88110_ext) = &floatformat_m88110_ext;
builtin_type_m88110_harris_ext =
init_type (TYPE_CODE_FLT, floatformat_m88110_harris_ext.totalsize / 8,
0, "builtin_type_m88110_harris_ext", NULL);
+ TYPE_FLOATFORMAT (builtin_type_m88110_harris_ext) = &floatformat_m88110_harris_ext;
builtin_type_arm_ext_big =
init_type (TYPE_CODE_FLT, floatformat_arm_ext_big.totalsize / 8,
0, "builtin_type_arm_ext_big", NULL);
+ TYPE_FLOATFORMAT (builtin_type_arm_ext_big) = &floatformat_arm_ext_big;
builtin_type_arm_ext_littlebyte_bigword =
init_type (TYPE_CODE_FLT, floatformat_arm_ext_littlebyte_bigword.totalsize / 8,
0, "builtin_type_arm_ext_littlebyte_bigword", NULL);
+ TYPE_FLOATFORMAT (builtin_type_arm_ext_littlebyte_bigword) = &floatformat_arm_ext_littlebyte_bigword;
builtin_type_ia64_spill_big =
init_type (TYPE_CODE_FLT, floatformat_ia64_spill_big.totalsize / 8,
0, "builtin_type_ia64_spill_big", NULL);
+ TYPE_FLOATFORMAT (builtin_type_ia64_spill_big) = &floatformat_ia64_spill_big;
builtin_type_ia64_spill_little =
init_type (TYPE_CODE_FLT, floatformat_ia64_spill_little.totalsize / 8,
0, "builtin_type_ia64_spill_little", NULL);
+ TYPE_FLOATFORMAT (builtin_type_ia64_spill_little) = &floatformat_ia64_spill_little;
builtin_type_ia64_quad_big =
init_type (TYPE_CODE_FLT, floatformat_ia64_quad_big.totalsize / 8,
0, "builtin_type_ia64_quad_big", NULL);
+ TYPE_FLOATFORMAT (builtin_type_ia64_quad_big) = &floatformat_ia64_quad_big;
builtin_type_ia64_quad_little =
init_type (TYPE_CODE_FLT, floatformat_ia64_quad_little.totalsize / 8,
0, "builtin_type_ia64_quad_little", NULL);
+ TYPE_FLOATFORMAT (builtin_type_ia64_quad_little) = &floatformat_ia64_quad_little;
add_show_from_set (
add_set_cmd ("overload", no_class, var_zinteger, (char *) &overload_debug,
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ARM floating point regs regression
2002-01-22 10:01 ` Andrew Cagney
@ 2002-01-22 10:10 ` Richard Earnshaw
0 siblings, 0 replies; 5+ messages in thread
From: Richard Earnshaw @ 2002-01-22 10:10 UTC (permalink / raw)
To: Andrew Cagney; +Cc: Richard.Earnshaw, gdb
> > I don't know how but almost all the lines initializing TYPE_FLOATFORMAT
> >> were lost.
> >>
>
>
> (try the attached, if it works, I'll add a few extra assertions so that the coredump can't occure).
Yes, that's solved the coredump problem. I've restarted a testrun to
check that that was the only problem. I'll post the results tomorrow (I'm
not hanging around all evening just to see what they are like ;-)
R.
^ permalink raw reply [flat|nested] 5+ messages in thread
* ARM floating point regs regression
@ 2002-01-23 3:45 Richard Earnshaw
2002-01-22 9:26 ` Andrew Cagney
0 siblings, 1 reply; 5+ messages in thread
From: Richard Earnshaw @ 2002-01-23 3:45 UTC (permalink / raw)
To: gdb, Andrew Cagney; +Cc: Richard.Earnshaw
Andrew,
The following regressions in the testsuite seem to be coming from this
patch:
2002-01-20 Andrew Cagney <ac131313@redhat.com>
* doublest.h (floatformat_from_type): Declare.
* doublest.c (floatformat_from_type): New function.
(convert_typed_floating): Use.
* valprint.c (print_floating): Replace checks for IEEE_FLOAT with
call to function floatformat_from_type.
All these occur after an "info all-registers", which causes gdb to
segfault:
ERROR: Couldn't send p t_char_values(0,0) to GDB.
UNRESOLVED: gdb.base/callfuncs.exp: p t_char_values(0,0)
ERROR: Couldn't send p t_char_values('a','b') to GDB.
UNRESOLVED: gdb.base/callfuncs.exp: p t_char_values('a','b')
ERROR: Couldn't send p t_char_values(char_val1,char_val2) to GDB.
UNRESOLVED: gdb.base/callfuncs.exp: p t_char_values(char_val1,char_val2)
ERROR: Couldn't send p t_char_values('a',char_val2) to GDB.
UNRESOLVED: gdb.base/callfuncs.exp: p t_char_values('a',char_val2)
ERROR: Couldn't send p t_char_values(char_val1,'b') to GDB.
UNRESOLVED: gdb.base/callfuncs.exp: p t_char_values(char_val1,'b')
ERROR: Couldn't send p t_short_values(0,0) to GDB.
UNRESOLVED: gdb.base/callfuncs.exp: p t_short_values(0,0)
ERROR: Couldn't send p t_short_values(10,-23) to GDB.
UNRESOLVED: gdb.base/callfuncs.exp: p t_short_values(10,-23)
ERROR: Couldn't send p t_short_values(short_val1,short_val2) to GDB.
UNRESOLVED: gdb.base/callfuncs.exp: p t_short_values(short_val1,short_val2)
ERROR: Couldn't send p t_short_values(10,short_val2) to GDB.
UNRESOLVED: gdb.base/callfuncs.exp: p t_short_values(10,short_val2)
(gdb) info all-reg
r0 0x0 0
r1 0x200c8774 537692020
r2 0x2 2
r3 0x200c877c 537692028
r4 0xefbfd334 -272641228
r5 0xefbfd264 -272641436
r6 0xefbfd26c -272641428
r7 0x1 1
r8 0x0 0
r9 0x0 0
r10 0x0 0
r11 0xefbfd238 -272641480
r12 0xefbfd204 -272641532
sp 0xefbfd22c -272641492
lr 0x1ccc 7372
pc 0x1bf8 7160
Program received signal SIGSEGV, Segmentation fault.
floatformat_is_nan (fmt=0x0, val=0xefbfcc14 "")
at /nfs/sun18//work/rearnsha/gnusrc/src/gdb/src/gdb/doublest.c:457
457 if (! fmt->exp_nan)
(top-gdb) p fmt
$1 = (struct floatformat *) 0x0
(top-gdb) where
#0 floatformat_is_nan (fmt=0x0, val=0xefbfcc14 "")
at /nfs/sun18//work/rearnsha/gnusrc/src/gdb/src/gdb/doublest.c:457
#1 0x0007ba4c in c_val_print (type=0x1c0d80, valaddr=0xefbfcc14 "",
embedded_offset=0, address=0, stream=0x1ae000, format=0, deref_ref=1,
recurse=0, pretty=Val_no_prettyprint)
at /nfs/sun18//work/rearnsha/gnusrc/src/gdb/src/gdb/c-valprint.c:439
#2 0x00016400 in val_print (type=0x1c0d80, valaddr=0xefbfcc14 "",
embedded_offset=0, address=0, stream=0x1ae000, format=0, deref_ref=1,
recurse=0, pretty=Val_pretty_default)
...
Breakpoint 3, print_floating (valaddr=0xefbfcc14 "", type=0x1c0d80,
stream=0x0)
at /nfs/sun18//work/rearnsha/gnusrc/src/gdb/src/gdb/valprint.c:551
551 const struct floatformat *fmt = floatformat_from_type (type);
(top-gdb) p type
$2 = (struct type *) 0x1c0d80
(top-gdb) p *type
$3 = {code = TYPE_CODE_FLT,
name = 0x527c8 "builtin_type_arm_ext_littlebyte_bigword", tag_name =
0x0,
length = 12, upper_bound_type = 0, lower_bound_type = 0, objfile = 0x0,
target_type = 0x0, pointer_type = 0x0, reference_type = 0x0,
cv_type = 0x1c0d80, as_type = 0x1c0d80, flags = 0, nfields = 0,
fields = 0x0, vptr_basetype = 0x0, vptr_fieldno = -1, type_specific = {
arg_types = 0x0, cplus_stuff = 0x0, floatformat = 0x0}}
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2002-01-23 11:45 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-01-23 3:45 ARM floating point regs regression Richard Earnshaw
2002-01-22 9:26 ` Andrew Cagney
2002-01-22 9:30 ` Richard Earnshaw
2002-01-22 10:01 ` Andrew Cagney
2002-01-22 10:10 ` Richard Earnshaw
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox