MMX registers on x86?

Mirror of the gdb mailing list
 help / color / mirror / Atom feed

* MMX registers on x86?
@ 1999-04-01  0:00 Jeff Epler
  1999-04-12 11:41 ` Jim Blandy
  0 siblings, 1 reply; 8+ messages in thread
From: Jeff Epler @ 1999-04-01  0:00 UTC (permalink / raw)
  To: gdb

I know folks are talking about floating point support in gdb, but what
about MMX (including 3dnow) registers?

In my work with 3dnow, I used as a solution a routine which stored the 8
mmx registers in memory, and I just examined that instead...

Jeff
-- 
\/ http://www.redhat.com/                        Jeff Epler jepler@inetnebr.com
Too much of everything is just enough.
		-- Bob Wier

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: MMX registers on x86?
  1999-04-01  0:00 MMX registers on x86? Jeff Epler
@ 1999-04-12 11:41 ` Jim Blandy
  1999-04-12 13:12   ` Jeff Epler
  1999-04-14 14:14   ` J.T. Conklin
  0 siblings, 2 replies; 8+ messages in thread
From: Jim Blandy @ 1999-04-12 11:41 UTC (permalink / raw)
  To: Jeff Epler; +Cc: gdb

> I know folks are talking about floating point support in gdb, but what
> about MMX (including 3dnow) registers?
> 
> In my work with 3dnow, I used as a solution a routine which stored the 8
> mmx registers in memory, and I just examined that instead...

I haven't heard of anyone else working on this.  Write a patch! :)


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: MMX registers on x86?
  1999-04-12 11:41 ` Jim Blandy
@ 1999-04-12 13:12   ` Jeff Epler
  1999-04-14 14:14   ` J.T. Conklin
  1 sibling, 0 replies; 8+ messages in thread
From: Jeff Epler @ 1999-04-12 13:12 UTC (permalink / raw)
  To: gdb

On Mon, Apr 12, 1999 at 01:40:57PM -0500, Jim Blandy wrote:
> 
> > I know folks are talking about floating point support in gdb, but what
> > about MMX (including 3dnow) registers?
> > 
> > In my work with 3dnow, I used as a solution a routine which stored the 8
> > mmx registers in memory, and I just examined that instead...
> 
> I haven't heard of anyone else working on this.  Write a patch! :)

I suspect that since one can already examine all 80 bits of the float
registers (?) that this is just a matter of writing the display code.
However, what do you do when the registers have so many different ways
of being looked at?  These come to mind:
	long double
	float[2]
	unsigned[4]
	signed[4]
	unsigned short[4]
	short[4]
	unsigned char[8]
	signed char[8]
worse, one might wish for %mm0 to be a float[2] but %mm1 to be
unsigned[4].  The type letters used by "x" are useful for this, but I'm
not quite sure how they would apply to "print %mm0" or "info registers".

Jeff
-- 
\/ jepler@inetnebr.com http://incolor.inetnebr.com/jepler/ (0|1(01*0)*1)+


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: MMX registers on x86?
  1999-04-12 11:41 ` Jim Blandy
  1999-04-12 13:12   ` Jeff Epler
@ 1999-04-14 14:14   ` J.T. Conklin
  1999-04-14 15:18     ` J.T. Conklin
  1999-04-14 16:43     ` Daniel Berlin
  1 sibling, 2 replies; 8+ messages in thread
From: J.T. Conklin @ 1999-04-14 14:14 UTC (permalink / raw)
  To: gdb; +Cc: Jeff Epler, Jim Blandy

>>>>> "Jim" == Jim Blandy <jimb@cygnus.com> writes:
>> I know folks are talking about floating point support in gdb, but
>> what about MMX (including 3dnow) registers?
>>
>> In my work with 3dnow, I used as a solution a routine which stored
>> the 8 mmx registers in memory, and I just examined that instead...

> I haven't heard of anyone else working on this.  Write a patch!
> :)

One thing I noticed about the x86 targets is that in many cases the
floating point registers are bolted on the side (obtained with info
float instead of info regs) if they are present at all, instead of
being first class citizens.

This may be a result of the tm-i386.h having NUM_FREG being defined as
0 (8 is commented out), and since most x86 target configs inherit base
definitions from that file, floating point support has been added only
sporadically.  Of the specific targets where floating point support
has been added, it appears that most have added it via the FLOAT_INFO
macro.  

FLOAT_INFO expands to a function that obtains FPU state (sometimes
with a ptrace call, sometimes by frobbing the u area directly, etc.)
and outputs the result.  The x86 float info functions produce nicely
formatted output, especially the FPU control and status words, but at
the expense of being able to set FPU registers within GDB, reading FPU
registers in core dumps, etc.

This is an all-to-easy comment to make now, but I believe what should
have happened is that the tm-i386.h file should have defined the FPU
registers as they are in the processor; and those targets that can't
support the FPU should have been forced to make whatever provisions
necessary to adjust.  It's a bit difficult to make that change now,
since it's hard to tell what targets are going to break because of
the chage.  

	--jtc

-- 
J.T. Conklin
RedBack Networks

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: MMX registers on x86?
  1999-04-14 14:14   ` J.T. Conklin
@ 1999-04-14 15:18     ` J.T. Conklin
  1999-04-14 16:43     ` Daniel Berlin
  1 sibling, 0 replies; 8+ messages in thread
From: J.T. Conklin @ 1999-04-14 15:18 UTC (permalink / raw)
  To: gdb; +Cc: Jeff Epler, Jim Blandy

>>>>> "Jim" == Jim Blandy <jimb@cygnus.com> writes:
>> I know folks are talking about floating point support in gdb, but
>> what about MMX (including 3dnow) registers?
>>
>> In my work with 3dnow, I used as a solution a routine which stored
>> the 8 mmx registers in memory, and I just examined that instead...

> I haven't heard of anyone else working on this.  Write a patch!
> :)

One thing I noticed about the x86 targets is that in many cases the
floating point registers are bolted on the side (obtained with info
float instead of info regs) if they are present at all, instead of
being first class citizens.

This may be a result of the tm-i386.h having NUM_FREG being defined as
0 (8 is commented out), and since most x86 target configs inherit base
definitions from that file, floating point support has been added only
sporadically.  Of the specific targets where floating point support
has been added, it appears that most have added it via the FLOAT_INFO
macro.  

FLOAT_INFO expands to a function that obtains FPU state (sometimes
with a ptrace call, sometimes by frobbing the u area directly, etc.)
and outputs the result.  The x86 float info functions produce nicely
formatted output, especially the FPU control and status words, but at
the expense of being able to set FPU registers within GDB, reading FPU
registers in core dumps, etc.

This is an all-to-easy comment to make now, but I believe what should
have happened is that the tm-i386.h file should have defined the FPU
registers as they are in the processor; and those targets that can't
support the FPU should have been forced to make whatever provisions
necessary to adjust.  It's a bit difficult to make that change now,
since it's hard to tell what targets are going to break because of
the chage.  

	--jtc

-- 
J.T. Conklin
RedBack Networks
From jkj@sco.com Wed Apr 14 15:20:00 1999
From: "J. Kean Johnston" <jkj@sco.com>
To: GDB Developers List <gdb@cygnus.com>
Subject: OSR5 test results for 4.18
Date: Wed, 14 Apr 1999 15:20:00 -0000
Message-id: <19990414141325.A898@sco.com>
X-SW-Source: 1999-04/msg00033.html
Content-length: 13822

All, below is the result of a test run for GDB 4.18 on SCO OpenServer 5.0.4:
(are these known issues or real ones on this platform?)

Results of tests in file gdb.sum:
FAIL: gdb.base/call-ar-st.exp: print print_small_structs
FAIL: gdb.base/call-ar-st.exp: print print_small_structs from print_long_arg_list
FAIL: gdb.base/call-ar-st.exp: print print_long_arg_list
FAIL: gdb.base/call-rt-st.exp: print print_struct_rep(*struct1, *struct2, *struct3)
FAIL: gdb.base/call-rt-st.exp: print print_one_large_struct(*list1)
FAIL: gdb.base/call-rt-st.exp: print print_one_double(*d1)
FAIL: gdb.base/call-rt-st.exp: print print_two_floats(*f3)
FAIL: gdb.base/call-rt-st.exp: print print_bit_flags(*flags)
FAIL: gdb.base/call-rt-st.exp: print print_bit_flags_combo(*flags_combo)
FAIL: gdb.base/call-rt-st.exp: print print_three_chars(*three_char)
FAIL: gdb.base/call-rt-st.exp: print print_five_chars(*five_char)
FAIL: gdb.base/call-rt-st.exp: print print_int_char_combo(*int_char_combo)
FAIL: gdb.base/callfuncs.exp: p t_float_values(3.14159,-2.3765)
FAIL: gdb.base/callfuncs.exp: p t_float_values(float_val1,float_val2)
FAIL: gdb.base/callfuncs.exp: p t_float_values(3.14159,float_val2)
FAIL: gdb.base/callfuncs.exp: p t_float_values(float_val1,-2.3765)
FAIL: gdb.base/callfuncs2.exp: p t_float_values(3.14159,-2.3765)
FAIL: gdb.base/callfuncs2.exp: p t_float_values(float_val1,float_val2)
FAIL: gdb.base/callfuncs2.exp: p t_float_values(3.14159,float_val2)
FAIL: gdb.base/callfuncs2.exp: p t_float_values(float_val1,-2.3765)
FAIL: gdb.base/commands.exp: continue in infrun_breakpoint_command_test
XPASS: gdb.base/constvars.exp: ptype lecherous
XPASS: gdb.base/constvars.exp: ptype lectern
FAIL: gdb.base/interrupt.exp: call function when asleep (stays asleep)
FAIL: gdb.base/langs.exp: up to foo in langs.exp
FAIL: gdb.base/langs.exp: show language at foo in langs.exp
FAIL: gdb.base/langs.exp: up to cppsub_ in langs.exp
FAIL: gdb.base/langs.exp: show language at cppsub_ in langs.exp
FAIL: gdb.base/langs.exp: up to fsub in langs.exp
FAIL: gdb.base/langs.exp: show language at fsub in langs.exp
XPASS: gdb.base/list.exp: list line 1 with listsize 1
XPASS: gdb.base/list.exp: list line 2 with listsize 1
XPASS: gdb.base/list.exp: list line 2 with listsize 3
XPASS: gdb.base/list.exp: list line 3 with listsize 3
FAIL: gdb.base/long_long.exp: octal print
FAIL: gdb.base/maint.exp: maint print psymbols
FAIL: gdb.base/maint.exp: maint print msymbols
FAIL: gdb.base/maint.exp: maint print symbols
XPASS: gdb.base/maint.exp: maint info breakpoints: shlib events
FAIL: gdb.base/miscexprs.exp: print value of &cbig.c[0]
FAIL: gdb.base/miscexprs.exp: print value of &sbig.s[0]
FAIL: gdb.base/miscexprs.exp: print value of &lbig.l[0]
FAIL: gdb.base/shlib-call.exp: re-run to bp in shared library (PR's 16495, 18213)
FAIL: gdb.base/shlib-call.exp: cont
FAIL: gdb.base/signals.exp: next to handler in signals_tests_1
FAIL: gdb.base/signals.exp: backtrace in signals_tests_1
FAIL: gdb.base/signals.exp: continue to handler: the program exited
FAIL: gdb.base/signals.exp: p count #1 in signals.exp
FAIL: gdb.base/signals.exp: p func1 () #2 in signals.exp
FAIL: gdb.base/signals.exp: bt in signals.exp
FAIL: gdb.base/signals.exp: continue in signals.exp: the program exited
FAIL: gdb.base/signals.exp: p count #2 in signals.exp
FAIL: gdb.base/signals.exp: signal without arguments disallowed
FAIL: gdb.base/signals.exp: sent signal 5
FAIL: gdb.base/smoke.exp: continue, hit watch
FAIL: gdb.base/smoke.exp: continue, 2nd hit watch
FAIL: gdb.base/smoke.exp: ptype
FAIL: gdb.base/smoke.exp: anon
FAIL: gdb.base/smoke.exp: print inherited class
FAIL: gdb.base/smoke.exp: set via print
FAIL: gdb.base/so-impl-ld.exp: implicit solibs tests suppressed
FAIL: gdb.base/so-impl-ld.exp: step over solib call
FAIL: gdb.base/so-impl-ld.exp: step into solib call
FAIL: gdb.base/so-impl-ld.exp: step in solib call
FAIL: gdb.base/so-impl-ld.exp: step out of solib call
FAIL: gdb.base/step-test.exp: stepi: finish call
FAIL: gdb.base/step-test.exp: nexti over function
FAIL: gdb.base/step-test.exp: run to pass large struct: the program is no longer running
FAIL: gdb.base/step-test.exp: large struct by value: the program is no longer running
FAIL: gdb.base/step-test.exp: run to finish: the program is no longer running
FAIL: gdb.base/varargs.exp: print find_max_double(5,1.0,17.0,2.0,3.0,4.0)
FAIL: gdb.c++/anon-union.exp: print foo 1
FAIL: gdb.c++/anon-union.exp: print foo 2
FAIL: gdb.c++/anon-union.exp: print foo 3
FAIL: gdb.c++/anon-union.exp: print foo 4
FAIL: gdb.c++/anon-union.exp: print foo 5
FAIL: gdb.c++/anon-union.exp: print foo 6
FAIL: gdb.c++/anon-union.exp: print foo 7
FAIL: gdb.c++/anon-union.exp: print foo 8
FAIL: gdb.c++/anon-union.exp: print foo 9
XPASS: gdb.c++/classes.exp: print (int)pmi == sizeof(int)
FAIL: gdb.c++/classes.exp: print bar.st
FAIL: gdb.c++/classes.exp: continue
FAIL: gdb.c++/classes.exp: print obj_with_enum (1)
FAIL: gdb.c++/classes.exp: print obj_with_enum (2)
FAIL: gdb.c++/classes.exp: ptype obj_with_enum.priv_enum
FAIL: gdb.c++/classes.exp: ptype obj_with_enum
FAIL: gdb.c++/classes.exp: print (ClassWithEnum::PrivEnum) 42
FAIL: gdb.c++/derivation.exp: ptype a_instance
FAIL: gdb.c++/derivation.exp: print value of d_instance
FAIL: gdb.c++/derivation.exp: ptype d_instance
FAIL: gdb.c++/derivation.exp: print value of e_instance
FAIL: gdb.c++/derivation.exp: ptype e_instance
FAIL: gdb.c++/derivation.exp: print value of f_instance
FAIL: gdb.c++/derivation.exp: ptype f_instance
FAIL: gdb.c++/derivation.exp: print value of d_instance.a
FAIL: gdb.c++/derivation.exp: print value of d_instance.aa
FAIL: gdb.c++/derivation.exp: print value of d_instance.b
FAIL: gdb.c++/derivation.exp: print value of d_instance.bb
FAIL: gdb.c++/derivation.exp: print value of d_instance.c
FAIL: gdb.c++/derivation.exp: print value of d_instance.cc
FAIL: gdb.c++/derivation.exp: print value of g_instance.afoo()
FAIL: gdb.c++/derivation.exp: print value of g_instance.bfoo()
FAIL: gdb.c++/derivation.exp: print value of g_instance.cfoo()
FAIL: gdb.c++/inherit.exp: ptype vA
FAIL: gdb.c++/inherit.exp: print g_vA.vA::va
FAIL: gdb.c++/inherit.exp: print g_vA.vA::vx
FAIL: gdb.c++/inherit.exp: print g_vB.vB::vb
FAIL: gdb.c++/inherit.exp: print g_vB.vB::vx
FAIL: gdb.c++/inherit.exp: print g_vD.vD::vd
FAIL: gdb.c++/inherit.exp: print g_vD.vD::vx
FAIL: gdb.c++/inherit.exp: print g_vE.vD::vx
FAIL: gdb.c++/inherit.exp: print g_vE.vE::ve
FAIL: gdb.c++/inherit.exp: print g_vE.vE::vx
FAIL: gdb.c++/member-ptr.exp: ptype pmi
FAIL: gdb.c++/member-ptr.exp: print pmi
FAIL: gdb.c++/member-ptr.exp: print a.*pmi
FAIL: gdb.c++/member-ptr.exp: print a->*pmi
FAIL: gdb.c++/member-ptr.exp: print pmi after setting
FAIL: gdb.c++/member-ptr.exp: print a.*pmi after setting
FAIL: gdb.c++/member-ptr.exp: print a.*pmi after resetting
FAIL: gdb.c++/member-ptr.exp: print command to set
FAIL: gdb.c++/member-ptr.exp: print a.*pmi after setting member pointed to
FAIL: gdb.c++/member-ptr.exp: print a after setting member pointed to by pmi
FAIL: gdb.c++/member-ptr.exp: print command to set (->)
FAIL: gdb.c++/member-ptr.exp: print a_p->*pmi after setting member pointed to
FAIL: gdb.c++/member-ptr.exp: print a after setting member pointed to by pmi (->)
FAIL: gdb.c++/member-ptr.exp: attempt to print ptr to member without object
FAIL: gdb.c++/member-ptr.exp: attempt to ptype ptr to member without object
FAIL: gdb.c++/member-ptr.exp: ptype pmf
FAIL: gdb.c++/member-ptr.exp: print pmf
FAIL: gdb.c++/member-ptr.exp: ptype pmf_p
FAIL: gdb.c++/member-ptr.exp: print pmf_p
FAIL: gdb.c++/member-ptr.exp: print a.*pmf -- ??
FAIL: gdb.c++/member-ptr.exp: print a_p->*pmf -- ??
FAIL: gdb.c++/member-ptr.exp: set var pmf -- ??
FAIL: gdb.c++/member-ptr.exp: attempt to print ptr to method without object
FAIL: gdb.c++/member-ptr.exp: attempt to ptype ptr to member without object
FAIL: gdb.c++/member-ptr.exp: casting pmi to int
FAIL: gdb.c++/member-ptr.exp: casting pmf to int -- ??
FAIL: gdb.c++/member-ptr.exp: print (a.*pmi)(3) -- ???
FAIL: gdb.c++/member-ptr.exp: print (a.*pmf)(3) -- ???
FAIL: gdb.c++/member-ptr.exp: next past 83
FAIL: gdb.c++/member-ptr.exp: print a.*NULL
FAIL: gdb.c++/member-ptr.exp: continue to 91
FAIL: gdb.c++/member-ptr.exp: print pmi (2)
FAIL: gdb.c++/member-ptr.exp: print a.*pmi (2)
FAIL: gdb.c++/member-ptr.exp: print a->*pmi (2)
FAIL: gdb.c++/method.exp: set breakpoint on A::foo
FAIL: gdb.c++/method.exp: continuing and breaking in A::foo
FAIL: gdb.c++/method.exp: print x (in foo)
FAIL: gdb.c++/method.exp: print this (in foo)
FAIL: gdb.c++/method.exp: set breakpoint on A::bar
FAIL: gdb.c++/method.exp: continuing and breaking in A::bar
FAIL: gdb.c++/method.exp: print x (in bar)
FAIL: gdb.c++/method.exp: print this (in bar)
FAIL: gdb.c++/method.exp: set breakpoint on funk::getfunky
FAIL: gdb.c++/method.exp: continuing and breaking in funk::getfunky
FAIL: gdb.c++/method.exp: print data_ in getFunky
FAIL: gdb.c++/method.exp: print this in getfunky
FAIL: gdb.c++/method.exp: print res in getfunky
FAIL: gdb.c++/method.exp: (timeout) ptype A
FAIL: gdb.c++/method.exp: finish program
FAIL: gdb.c++/overload.exp: ptype foo_instance1
FAIL: gdb.c++/overload.exp: print call overloaded func 1 arg
FAIL: gdb.c++/overload.exp: print call overloaded func 2 args
FAIL: gdb.c++/overload.exp: print call overloaded func 3 args
FAIL: gdb.c++/overload.exp: print call overloaded func 4 args
FAIL: gdb.c++/overload.exp: print call overloaded func 5 args
FAIL: gdb.c++/overload.exp: print call overloaded func 6 args
FAIL: gdb.c++/overload.exp: print call overloaded func 7 args
FAIL: gdb.c++/overload.exp: print call overloaded func 8 args
FAIL: gdb.c++/overload.exp: print call overloaded func 9 args
FAIL: gdb.c++/overload.exp: print call overloaded func 10 args
FAIL: gdb.c++/overload.exp: print call overloaded func 11 args
FAIL: gdb.c++/overload.exp: print call overloaded func void arg
FAIL: gdb.c++/overload.exp: print call overloaded func char arg
FAIL: gdb.c++/overload.exp: print call overloaded func signed char arg
FAIL: gdb.c++/overload.exp: print call overloaded func unsigned char arg
FAIL: gdb.c++/overload.exp: print call overloaded func short arg
FAIL: gdb.c++/overload.exp: print call overloaded func unsigned short  arg
FAIL: gdb.c++/overload.exp: print call overloaded func int arg
FAIL: gdb.c++/overload.exp: print call overloaded func unsigned int arg
FAIL: gdb.c++/overload.exp: print call overloaded func long arg
FAIL: gdb.c++/overload.exp: print call overloaded func unsigned long arg
FAIL: gdb.c++/overload.exp: print call overloaded func float arg
FAIL: gdb.c++/overload.exp: print call overloaded func double arg
FAIL: gdb.c++/ovldbreak.exp: set bp on overload1arg(char)(wrong menu)
FAIL: gdb.c++/ovldbreak.exp: breakpoint info
FAIL: gdb.c++/ovldbreak.exp: set bp on overload1arg(signed char)(wrong menu)
FAIL: gdb.c++/ovldbreak.exp: breakpoint info
FAIL: gdb.c++/ovldbreak.exp: set bp on overload1arg(unsigned char)(wrong menu)
FAIL: gdb.c++/ovldbreak.exp: breakpoint info
FAIL: gdb.c++/ovldbreak.exp: set bp on overload1arg(short)(wrong menu)
FAIL: gdb.c++/ovldbreak.exp: breakpoint info
FAIL: gdb.c++/ovldbreak.exp: set bp on overload1arg(unsigned short)(wrong menu)
FAIL: gdb.c++/ovldbreak.exp: breakpoint info
FAIL: gdb.c++/ovldbreak.exp: set bp on overload1arg(int)(wrong menu)
FAIL: gdb.c++/ovldbreak.exp: breakpoint info
FAIL: gdb.c++/ovldbreak.exp: set bp on overload1arg(unsigned int)(wrong menu)
FAIL: gdb.c++/ovldbreak.exp: breakpoint info
FAIL: gdb.c++/ovldbreak.exp: set bp on overload1arg(long)(wrong menu)
FAIL: gdb.c++/ovldbreak.exp: breakpoint info
FAIL: gdb.c++/ovldbreak.exp: set bp on overload1arg(unsigned long)(wrong menu)
FAIL: gdb.c++/ovldbreak.exp: breakpoint info
FAIL: gdb.c++/ovldbreak.exp: set bp on overload1arg(float)(wrong menu)
FAIL: gdb.c++/ovldbreak.exp: breakpoint info
FAIL: gdb.c++/ovldbreak.exp: set bp on overload1arg(double)(wrong menu)
FAIL: gdb.c++/ovldbreak.exp: breakpoint info
FAIL: gdb.c++/ovldbreak.exp: set bp on overload1arg(void)(wrong menu)
FAIL: gdb.c++/ovldbreak.exp: breakpoint info
FAIL: gdb.c++/ovldbreak.exp: set bp cancelled(wrong menu)
FAIL: gdb.c++/ovldbreak.exp: breakpoint info
FAIL: gdb.c++/ovldbreak.exp: set bp on all overload1arg()(wrong menu)
FAIL: gdb.c++/ovldbreak.exp: breakpoint info
FAIL: gdb.c++/ovldbreak.exp: continue to bp overloaded : void
FAIL: gdb.c++/ovldbreak.exp: continue to bp overloaded : char
FAIL: gdb.c++/ovldbreak.exp: continue to bp overloaded : signed char
FAIL: gdb.c++/ovldbreak.exp: continue to bp overloaded : unsigned char
FAIL: gdb.c++/ovldbreak.exp: continue to bp overloaded : short
FAIL: gdb.c++/ovldbreak.exp: continue to bp overloaded : unsigned short
FAIL: gdb.c++/ovldbreak.exp: continue to bp overloaded : int
FAIL: gdb.c++/ovldbreak.exp: continue to bp overloaded : unsigned int
FAIL: gdb.c++/ovldbreak.exp: continue to bp overloaded : long
FAIL: gdb.c++/ovldbreak.exp: continue to bp overloaded : unsigned long
FAIL: gdb.c++/ovldbreak.exp: continue to bp overloaded : float
FAIL: gdb.c++/ovldbreak.exp: continue to bp overloaded : double
FAIL: gdb.c++/ovldbreak.exp: finish program
FAIL: gdb.c++/templates.exp: ptype T5<int> (timeout)
FAIL: gdb.c++/templates.exp: ptype t5i (timeout)
FAIL: gdb.c++/templates.exp: constructor breakpoint (timeout)
FAIL: gdb.c++/templates.exp: destructor breakpoint
FAIL: gdb.c++/templates.exp: value method breakpoint
		=== gdb Summary ===
# of expected passes		5288
# of unexpected failures	225
# of unexpected successes	8
# of expected failures		233
# of unresolved testcases	5
 
-- 
J. Kean Johnston  | "Only the dead have seen an end to war"
Engineer, SPG     |                                         -- Plato
Santa Cruz, CA    +----------------------------------------------------------
Tel: 831-427-7569    Fax: 831-429-1887    E-mail: jkj@sco.com
From shebs@cygnus.com Wed Apr 14 17:52:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: jkj@sco.com
Cc: gdb@cygnus.com
Subject: Re: OSR5 test results for 4.18
Date: Wed, 14 Apr 1999 17:52:00 -0000
Message-id: <199904142340.QAA14710@andros.cygnus.com>
References: <19990414141325.A898@sco.com>
X-SW-Source: 1999-04/msg00034.html
Content-length: 3707

   Date: Wed, 14 Apr 1999 14:13:25 -0700
   From: "J. Kean Johnston" <jkj@sco.com>

   All, below is the result of a test run for GDB 4.18 on SCO OpenServer 5.0.4:

There are about 100 failures that still occur with all native configs,
such as the ones in member-ptr.exp and overload.exp.  However, the
following failures are not (for instance) happening on Linux, and
should therefore cause you some concern:

   FAIL: gdb.base/call-rt-st.exp: print print_struct_rep(*struct1, *struct2, *struct3)
   FAIL: gdb.base/call-rt-st.exp: print print_one_large_struct(*list1)
   FAIL: gdb.base/call-rt-st.exp: print print_one_double(*d1)
   FAIL: gdb.base/call-rt-st.exp: print print_two_floats(*f3)
   FAIL: gdb.base/call-rt-st.exp: print print_bit_flags(*flags)
   FAIL: gdb.base/call-rt-st.exp: print print_bit_flags_combo(*flags_combo)
   FAIL: gdb.base/call-rt-st.exp: print print_three_chars(*three_char)
   FAIL: gdb.base/call-rt-st.exp: print print_five_chars(*five_char)
   FAIL: gdb.base/call-rt-st.exp: print print_int_char_combo(*int_char_combo)
   FAIL: gdb.base/callfuncs.exp: p t_float_values(3.14159,-2.3765)
   FAIL: gdb.base/callfuncs.exp: p t_float_values(float_val1,float_val2)
   FAIL: gdb.base/callfuncs.exp: p t_float_values(3.14159,float_val2)
   FAIL: gdb.base/callfuncs.exp: p t_float_values(float_val1,-2.3765)
   FAIL: gdb.base/callfuncs2.exp: p t_float_values(3.14159,-2.3765)
   FAIL: gdb.base/callfuncs2.exp: p t_float_values(float_val1,float_val2)
   FAIL: gdb.base/callfuncs2.exp: p t_float_values(3.14159,float_val2)
   FAIL: gdb.base/callfuncs2.exp: p t_float_values(float_val1,-2.3765)

   FAIL: gdb.base/langs.exp: up to foo in langs.exp
   FAIL: gdb.base/langs.exp: show language at foo in langs.exp
   FAIL: gdb.base/langs.exp: up to cppsub_ in langs.exp
   FAIL: gdb.base/langs.exp: show language at cppsub_ in langs.exp
   FAIL: gdb.base/langs.exp: up to fsub in langs.exp
   FAIL: gdb.base/langs.exp: show language at fsub in langs.exp

   FAIL: gdb.base/maint.exp: maint print psymbols
   FAIL: gdb.base/maint.exp: maint print msymbols
   FAIL: gdb.base/maint.exp: maint print symbols

   FAIL: gdb.base/signals.exp: next to handler in signals_tests_1
   FAIL: gdb.base/signals.exp: backtrace in signals_tests_1
   FAIL: gdb.base/signals.exp: continue to handler: the program exited
   FAIL: gdb.base/signals.exp: p count #1 in signals.exp
   FAIL: gdb.base/signals.exp: p func1 () #2 in signals.exp
   FAIL: gdb.base/signals.exp: bt in signals.exp
   FAIL: gdb.base/signals.exp: continue in signals.exp: the program exited
   FAIL: gdb.base/signals.exp: p count #2 in signals.exp
   FAIL: gdb.base/signals.exp: signal without arguments disallowed
   FAIL: gdb.base/signals.exp: sent signal 5

   FAIL: gdb.base/so-impl-ld.exp: implicit solibs tests suppressed
   FAIL: gdb.base/so-impl-ld.exp: step over solib call
   FAIL: gdb.base/so-impl-ld.exp: step into solib call
   FAIL: gdb.base/so-impl-ld.exp: step in solib call
   FAIL: gdb.base/so-impl-ld.exp: step out of solib call

   FAIL: gdb.base/step-test.exp: stepi: finish call
   FAIL: gdb.base/step-test.exp: nexti over function
   FAIL: gdb.base/step-test.exp: run to pass large struct: the program is no longer running
   FAIL: gdb.base/step-test.exp: large struct by value: the program is no longer running
   FAIL: gdb.base/step-test.exp: run to finish: the program is no longer running
   FAIL: gdb.base/varargs.exp: print find_max_double(5,1.0,17.0,2.0,3.0,4.0)

This pattern of failures doesn't suggest anything obvious to me, so
you may be hitting a combination of problems.  Some of these failures
tend to be associated with bad debug info from the compiler - which
compiler are you using?

								Stan
From dberlin@msn.com Wed Apr 14 17:53:00 1999
From: "Daniel Berlin" <dberlin@msn.com>
To: <jtc@redback.com>, <gdb@cygnus.com>
Cc: "Jeff Epler" <jepler@inetnebr.com>, "Jim Blandy" <jimb@cygnus.com>
Subject: Re: MMX registers on x86?
Date: Wed, 14 Apr 1999 17:53:00 -0000
Message-id: <001d01be8799$59947480$8d8f9780@DANIELBE>
References: <19990312122003.A25822@craie.inetnebr.com> <npr9pp1y2u.fsf@zwingli.cygnus.com> <5m7lrevrc4.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-04/msg00035.html
Content-length: 1162

However, it might be better to just add some mechanism to define "special"
registers (Fer instance, ,3dnow/KNI/MMX) that are in some way different from
the rest of the processor registers, be it in size/usage/whatever.
I'm about to add KNI support to the BeOS port, as well as MMX and 3DNow
support, and i'd rather have some standard supported way of doing it than
making another hack that someone will have to futz with and learn the
reasoning behind a year or two down the line.  Or when something like
Altivec comes along, it wouldn't take major retrofitting and port hacking
(every single target that can run on that processor with a different -nat
file) to do.
--Dan
>
> This is an all-to-easy comment to make now, but I believe what should
> have happened is that the tm-i386.h file should have defined the FPU
> registers as they are in the processor; and those targets that can't
> support the FPU should have been forced to make whatever provisions
> necessary to adjust.  It's a bit difficult to make that change now,
> since it's hard to tell what targets are going to break because of
> the chage.
>
> --jtc
>
> --
> J.T. Conklin
> RedBack Networks


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: MMX registers on x86?
  1999-04-14 14:14   ` J.T. Conklin
  1999-04-14 15:18     ` J.T. Conklin
@ 1999-04-14 16:43     ` Daniel Berlin
  1999-04-14 17:59       ` Stan Shebs
  1 sibling, 1 reply; 8+ messages in thread
From: Daniel Berlin @ 1999-04-14 16:43 UTC (permalink / raw)
  To: jtc, gdb; +Cc: Jeff Epler, Jim Blandy

However, it might be better to just add some mechanism to define "special"
registers (Fer instance, ,3dnow/KNI/MMX) that are in some way different from
the rest of the processor registers, be it in size/usage/whatever.
I'm about to add KNI support to the BeOS port, as well as MMX and 3DNow
support, and i'd rather have some standard supported way of doing it than
making another hack that someone will have to futz with and learn the
reasoning behind a year or two down the line.  Or when something like
Altivec comes along, it wouldn't take major retrofitting and port hacking
(every single target that can run on that processor with a different -nat
file) to do.
--Dan
>
> This is an all-to-easy comment to make now, but I believe what should
> have happened is that the tm-i386.h file should have defined the FPU
> registers as they are in the processor; and those targets that can't
> support the FPU should have been forced to make whatever provisions
> necessary to adjust.  It's a bit difficult to make that change now,
> since it's hard to tell what targets are going to break because of
> the chage.
>
> --jtc
>
> --
> J.T. Conklin
> RedBack Networks



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: MMX registers on x86?
  1999-04-14 16:43     ` Daniel Berlin
@ 1999-04-14 17:59       ` Stan Shebs
  1999-04-14 18:55         ` Stan Shebs
  0 siblings, 1 reply; 8+ messages in thread
From: Stan Shebs @ 1999-04-14 17:59 UTC (permalink / raw)
  To: dberlin; +Cc: jtc, gdb, jepler, jimb

   From: "Daniel Berlin" <dberlin@msn.com>
   Date: Thu, 15 Apr 1999 19:40:26 -0400

   However, it might be better to just add some mechanism to define "special"
   registers (Fer instance, ,3dnow/KNI/MMX) that are in some way different from
   the rest of the processor registers, be it in size/usage/whatever.
   I'm about to add KNI support to the BeOS port, as well as MMX and 3DNow
   support, and i'd rather have some standard supported way of doing it than
   making another hack that someone will have to futz with and learn the
   reasoning behind a year or two down the line.  Or when something like
   Altivec comes along, it wouldn't take major retrofitting and port hacking
   (every single target that can run on that processor with a different -nat
   file) to do.

Andrew Cagney has been working on some infrastructure that will, among
other things, greatly simplify handling of special registers and
multiple register sets.  He's supposed to send a long detailed message
to this list in a few days.  We're hoping to roll the code out into the
sources this month, give people a crack at it.

							Stan

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: MMX registers on x86?
  1999-04-14 17:59       ` Stan Shebs
@ 1999-04-14 18:55         ` Stan Shebs
  0 siblings, 0 replies; 8+ messages in thread
From: Stan Shebs @ 1999-04-14 18:55 UTC (permalink / raw)
  To: dberlin; +Cc: jtc, gdb, jepler, jimb

   From: "Daniel Berlin" <dberlin@msn.com>
   Date: Thu, 15 Apr 1999 19:40:26 -0400

   However, it might be better to just add some mechanism to define "special"
   registers (Fer instance, ,3dnow/KNI/MMX) that are in some way different from
   the rest of the processor registers, be it in size/usage/whatever.
   I'm about to add KNI support to the BeOS port, as well as MMX and 3DNow
   support, and i'd rather have some standard supported way of doing it than
   making another hack that someone will have to futz with and learn the
   reasoning behind a year or two down the line.  Or when something like
   Altivec comes along, it wouldn't take major retrofitting and port hacking
   (every single target that can run on that processor with a different -nat
   file) to do.

Andrew Cagney has been working on some infrastructure that will, among
other things, greatly simplify handling of special registers and
multiple register sets.  He's supposed to send a long detailed message
to this list in a few days.  We're hoping to roll the code out into the
sources this month, give people a crack at it.

							Stan

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~1999-04-14 18:55 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-04-01  0:00 MMX registers on x86? Jeff Epler
1999-04-12 11:41 ` Jim Blandy
1999-04-12 13:12   ` Jeff Epler
1999-04-14 14:14   ` J.T. Conklin
1999-04-14 15:18     ` J.T. Conklin
1999-04-14 16:43     ` Daniel Berlin
1999-04-14 17:59       ` Stan Shebs
1999-04-14 18:55         ` Stan Shebs

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox