RFA: GCC stabs don't contain prototype info

RFA: GCC stabs don't contain prototype info

[Jim Blandy]

This comes as a bit of a surprise to me, but it seems that stabs
generated by GCC don't indicate whether a given function was defined
with a prototype or not.  The argument types should appear after the
return types, each preceded by a semicolon, but for the following
input program:

        int foo (int a, float b) { return a + b; }

`gcc -save-temps -O2 -g -c' generates the following relevant stabs:

    .stabs "int:t(0,1)=r(0,1);0020000000000;0017777777777;",128,0,0,0
    .stabs "float:t(0,12)=r(0,1);4;0;",128,0,0,0
    .stabs "foo:F(0,1)",36,0,1,foo
    .stabs "a:P(0,1)",64,0,1,8
    .stabs "b:P(0,12)",64,0,1,9
    .stabs "",36,0,0,.LLscope0-foo
            .stabs "",100,0,0,.Letext

There is no no prototype info here.  There's no way for GDB to know
that the function expects its second argument to be passed as a float,
not promoted to a double, as the K&R-style rules specify.

Thus:

2001-11-26  Jim Blandy  <jimb@redhat.com>

	* gdb.base/callfuncs.exp: The stabs generated by GCC don't tell us
	whether functions are prototyped or not, so we can't possibly pass
	arguments to t_float_values2 properly.

Index: gdb/testsuite/gdb.base/callfuncs.exp
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/testsuite/gdb.base/callfuncs.exp,v
retrieving revision 1.46
diff -c -r1.46 callfuncs.exp
*** gdb/testsuite/gdb.base/callfuncs.exp	2001/11/10 00:08:23	1.46
--- gdb/testsuite/gdb.base/callfuncs.exp	2001/11/27 03:24:59
***************
*** 142,147 ****
--- 142,150 ----
  	gdb_test "p t_float_values(float_val1,-2.3765)" " = 1"
  
  	# Test passing of arguments which might not be widened.
+         # Under stabs, GCC doesn't tell us whether the function was
+         # prototyped or not.
+         if {$gcc_compiled} { setup_xfail_format "stabs" }
  	gdb_test "p t_float_values2(0.0,0.0)" " = 0"
  
  	# Although PR 5318 mentions SunOS specifically, this seems
***************
*** 152,158 ****
--- 155,166 ----
  		setup_xfail "alpha-dec-osf2*" "i*86-*-sysv4*" 5318
  	    }
  	}
+         
+         # Under stabs, GCC doesn't tell us whether the function was
+         # prototyped or not.
+         if {$gcc_compiled} { setup_xfail_format "stabs" }
  	gdb_test "p t_float_values2(3.14159,float_val2)" " = 1"
+ 
  	gdb_test "p t_small_values(1,2,3,4,5,6,7,8,9,10)" " = 55"
  
  	gdb_test "p t_double_values(0.0,0.0)" " = 0"
***************
*** 289,294 ****
--- 297,304 ----
  	}
      }
  }
+ 
+ get_debug_format
  
  # Make sure that malloc gets called and that the floating point unit
  # is initialized via a call to t_double_values.

RFA: GCC stabs don't contain prototype info

[Jim Blandy]

This comes as a bit of a surprise to me, but it seems that stabs
generated by GCC don't indicate whether a given function was defined
with a prototype or not.  The argument types should appear after the
return types, each preceded by a semicolon, but for the following
input program:

        int foo (int a, float b) { return a + b; }

`gcc -save-temps -O2 -g -c' generates the following relevant stabs:

    .stabs "int:t(0,1)=r(0,1);0020000000000;0017777777777;",128,0,0,0
    .stabs "float:t(0,12)=r(0,1);4;0;",128,0,0,0
    .stabs "foo:F(0,1)",36,0,1,foo
    .stabs "a:P(0,1)",64,0,1,8
    .stabs "b:P(0,12)",64,0,1,9
    .stabs "",36,0,0,.LLscope0-foo
            .stabs "",100,0,0,.Letext

There is no no prototype info here.  There's no way for GDB to know
that the function expects its second argument to be passed as a float,
not promoted to a double, as the K&R-style rules specify.

Thus:

2001-11-26  Jim Blandy  <jimb@redhat.com>

	* gdb.base/callfuncs.exp: The stabs generated by GCC don't tell us
	whether functions are prototyped or not, so we can't possibly pass
	arguments to t_float_values2 properly.

Index: gdb/testsuite/gdb.base/callfuncs.exp
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/testsuite/gdb.base/callfuncs.exp,v
retrieving revision 1.46
diff -c -r1.46 callfuncs.exp
*** gdb/testsuite/gdb.base/callfuncs.exp	2001/11/10 00:08:23	1.46
--- gdb/testsuite/gdb.base/callfuncs.exp	2001/11/27 03:24:59
***************
*** 142,147 ****
--- 142,150 ----
  	gdb_test "p t_float_values(float_val1,-2.3765)" " = 1"
  
  	# Test passing of arguments which might not be widened.
+         # Under stabs, GCC doesn't tell us whether the function was
+         # prototyped or not.
+         if {$gcc_compiled} { setup_xfail_format "stabs" }
  	gdb_test "p t_float_values2(0.0,0.0)" " = 0"
  
  	# Although PR 5318 mentions SunOS specifically, this seems
***************
*** 152,158 ****
--- 155,166 ----
  		setup_xfail "alpha-dec-osf2*" "i*86-*-sysv4*" 5318
  	    }
  	}
+         
+         # Under stabs, GCC doesn't tell us whether the function was
+         # prototyped or not.
+         if {$gcc_compiled} { setup_xfail_format "stabs" }
  	gdb_test "p t_float_values2(3.14159,float_val2)" " = 1"
+ 
  	gdb_test "p t_small_values(1,2,3,4,5,6,7,8,9,10)" " = 55"
  
  	gdb_test "p t_double_values(0.0,0.0)" " = 0"
***************
*** 289,294 ****
--- 297,304 ----
  	}
      }
  }
+ 
+ get_debug_format
  
  # Make sure that malloc gets called and that the floating point unit
  # is initialized via a call to t_double_values.

Re: RFA: GCC stabs don't contain prototype info

[Daniel Jacobowitz]

On Mon, Nov 26, 2001 at 10:44:23PM -0500, Jim Blandy wrote:
> 
> This comes as a bit of a surprise to me, but it seems that stabs
> generated by GCC don't indicate whether a given function was defined
> with a prototype or not.  The argument types should appear after the
> return types, each preceded by a semicolon, but for the following
> input program:
> 
>         int foo (int a, float b) { return a + b; }
> 
> `gcc -save-temps -O2 -g -c' generates the following relevant stabs:
> 
>     .stabs "int:t(0,1)=r(0,1);0020000000000;0017777777777;",128,0,0,0
>     .stabs "float:t(0,12)=r(0,1);4;0;",128,0,0,0
>     .stabs "foo:F(0,1)",36,0,1,foo
>     .stabs "a:P(0,1)",64,0,1,8
>     .stabs "b:P(0,12)",64,0,1,9
>     .stabs "",36,0,0,.LLscope0-foo
>             .stabs "",100,0,0,.Letext
> 
> There is no no prototype info here.  There's no way for GDB to know
> that the function expects its second argument to be passed as a float,
> not promoted to a double, as the K&R-style rules specify.

Is there a standard stabs convention for this?  If so, it would be a
good idea to make development GCC emit it.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: GCC stabs don't contain prototype info

[Daniel Jacobowitz]

On Mon, Nov 26, 2001 at 10:44:23PM -0500, Jim Blandy wrote:
> 
> This comes as a bit of a surprise to me, but it seems that stabs
> generated by GCC don't indicate whether a given function was defined
> with a prototype or not.  The argument types should appear after the
> return types, each preceded by a semicolon, but for the following
> input program:
> 
>         int foo (int a, float b) { return a + b; }
> 
> `gcc -save-temps -O2 -g -c' generates the following relevant stabs:
> 
>     .stabs "int:t(0,1)=r(0,1);0020000000000;0017777777777;",128,0,0,0
>     .stabs "float:t(0,12)=r(0,1);4;0;",128,0,0,0
>     .stabs "foo:F(0,1)",36,0,1,foo
>     .stabs "a:P(0,1)",64,0,1,8
>     .stabs "b:P(0,12)",64,0,1,9
>     .stabs "",36,0,0,.LLscope0-foo
>             .stabs "",100,0,0,.Letext
> 
> There is no no prototype info here.  There's no way for GDB to know
> that the function expects its second argument to be passed as a float,
> not promoted to a double, as the K&R-style rules specify.

Is there a standard stabs convention for this?  If so, it would be a
good idea to make development GCC emit it.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: GCC stabs don't contain prototype info

[Jim Blandy]

Daniel Jacobowitz <drow@mvista.com> writes:
> Is there a standard stabs convention for this?  If so, it would be a
> good idea to make development GCC emit it.

Yes, there's the encoding developed by Sun, described in the GNU stabs
manual.  It looks to me like GDB is ready to consume this info, so
getting GCC to emit it would be great.

Until that's done, however, this test should XFAIL, so other engineers
won't waste their time re-analyzing the failure.  (I don't mean to
imply that you disagree; I just want to make things clear to the test
suite maintainers.)

Re: RFA: GCC stabs don't contain prototype info

[Jim Blandy]

Daniel Jacobowitz <drow@mvista.com> writes:
> Is there a standard stabs convention for this?  If so, it would be a
> good idea to make development GCC emit it.

Yes, there's the encoding developed by Sun, described in the GNU stabs
manual.  It looks to me like GDB is ready to consume this info, so
getting GCC to emit it would be great.

Until that's done, however, this test should XFAIL, so other engineers
won't waste their time re-analyzing the failure.  (I don't mean to
imply that you disagree; I just want to make things clear to the test
suite maintainers.)

Re: RFA: GCC stabs don't contain prototype info

[Michael Snyder]

Jim Blandy wrote:
> 
> Daniel Jacobowitz <drow@mvista.com> writes:
> > Is there a standard stabs convention for this?  If so, it would be a
> > good idea to make development GCC emit it.
> 
> Yes, there's the encoding developed by Sun, described in the GNU stabs
> manual.  It looks to me like GDB is ready to consume this info, so
> getting GCC to emit it would be great.
> 
> Until that's done, however, this test should XFAIL, so other engineers
> won't waste their time re-analyzing the failure.  (I don't mean to
> imply that you disagree; I just want to make things clear to the test
> suite maintainers.)

FYI, it is not only stabs that fails this test.  I've got a recent
elf/dwarf target that also fails it.  The problem wherein GDB cannot
reliably make this distinction is long standing, and much discussed
in the past.  Unfortunately most of the people who have taken part
in this discussion aren't around any more.

Re: RFA: GCC stabs don't contain prototype info

[Michael Snyder]

Jim Blandy wrote:
> 
> Daniel Jacobowitz <drow@mvista.com> writes:
> > Is there a standard stabs convention for this?  If so, it would be a
> > good idea to make development GCC emit it.
> 
> Yes, there's the encoding developed by Sun, described in the GNU stabs
> manual.  It looks to me like GDB is ready to consume this info, so
> getting GCC to emit it would be great.
> 
> Until that's done, however, this test should XFAIL, so other engineers
> won't waste their time re-analyzing the failure.  (I don't mean to
> imply that you disagree; I just want to make things clear to the test
> suite maintainers.)

FYI, it is not only stabs that fails this test.  I've got a recent
elf/dwarf target that also fails it.  The problem wherein GDB cannot
reliably make this distinction is long standing, and much discussed
in the past.  Unfortunately most of the people who have taken part
in this discussion aren't around any more.

Re: RFA: GCC stabs don't contain prototype info

[Daniel Berlin]

On Tue, 27 Nov 2001, Michael Snyder wrote:

> Jim Blandy wrote:
> >
> > Daniel Jacobowitz <drow@mvista.com> writes:
> > > Is there a standard stabs convention for this?  If so, it would be a
> > > good idea to make development GCC emit it.
> >
> > Yes, there's the encoding developed by Sun, described in the GNU stabs
> > manual.  It looks to me like GDB is ready to consume this info, so
> > getting GCC to emit it would be great.
> >
> > Until that's done, however, this test should XFAIL, so other engineers
> > won't waste their time re-analyzing the failure.  (I don't mean to
> > imply that you disagree; I just want to make things clear to the test
> > suite maintainers.)
>
> FYI, it is not only stabs that fails this test.  I've got a recent
> elf/dwarf target that also fails it.

Err, it shouldn't.
Unless you really mean dwarf and not dwarf2.
GCC adds DW_AT_prototyped to prototyped functions.
And gdb consumes it.

> The problem wherein GDB cannot
> reliably make this distinction is long standing, and much discussed
> in the past.  Unfortunately most of the people who have taken part
> in this discussion aren't around any more.
>

Re: RFA: GCC stabs don't contain prototype info

[Daniel Berlin]

On Tue, 27 Nov 2001, Michael Snyder wrote:

> Jim Blandy wrote:
> >
> > Daniel Jacobowitz <drow@mvista.com> writes:
> > > Is there a standard stabs convention for this?  If so, it would be a
> > > good idea to make development GCC emit it.
> >
> > Yes, there's the encoding developed by Sun, described in the GNU stabs
> > manual.  It looks to me like GDB is ready to consume this info, so
> > getting GCC to emit it would be great.
> >
> > Until that's done, however, this test should XFAIL, so other engineers
> > won't waste their time re-analyzing the failure.  (I don't mean to
> > imply that you disagree; I just want to make things clear to the test
> > suite maintainers.)
>
> FYI, it is not only stabs that fails this test.  I've got a recent
> elf/dwarf target that also fails it.

Err, it shouldn't.
Unless you really mean dwarf and not dwarf2.
GCC adds DW_AT_prototyped to prototyped functions.
And gdb consumes it.

> The problem wherein GDB cannot
> reliably make this distinction is long standing, and much discussed
> in the past.  Unfortunately most of the people who have taken part
> in this discussion aren't around any more.
>

Re: RFA: GCC stabs don't contain prototype info

[Jim Blandy]

Daniel Berlin <dan@cgsoftware.com> writes:
> > FYI, it is not only stabs that fails this test.  I've got a recent
> > elf/dwarf target that also fails it.
> 
> Err, it shouldn't.
> Unless you really mean dwarf and not dwarf2.
> GCC adds DW_AT_prototyped to prototyped functions.
> And gdb consumes it.

With Dwarf 2, GDB always has enough information to do the right
thing, but it doesn't use it.

At the moment, a function type can have its TYPE_FLAG_PROTOTYPED flag
set or clear.  Stabs doesn't set it reliably; Dwarf 2 does.  But the
code which checks this flag doesn't know where its setting came from,
so it doesn't know whether it should trust it or not.  There's an
arch-specific macro which says whether it should.  *gag*

Re: RFA: GCC stabs don't contain prototype info

[Jim Blandy]

Daniel Berlin <dan@cgsoftware.com> writes:
> > FYI, it is not only stabs that fails this test.  I've got a recent
> > elf/dwarf target that also fails it.
> 
> Err, it shouldn't.
> Unless you really mean dwarf and not dwarf2.
> GCC adds DW_AT_prototyped to prototyped functions.
> And gdb consumes it.

With Dwarf 2, GDB always has enough information to do the right
thing, but it doesn't use it.

At the moment, a function type can have its TYPE_FLAG_PROTOTYPED flag
set or clear.  Stabs doesn't set it reliably; Dwarf 2 does.  But the
code which checks this flag doesn't know where its setting came from,
so it doesn't know whether it should trust it or not.  There's an
arch-specific macro which says whether it should.  *gag*

Re: RFA: GCC stabs don't contain prototype info

[Michael Snyder]

Jim Blandy wrote:
> 
> This comes as a bit of a surprise to me, but it seems that stabs
> generated by GCC don't indicate whether a given function was defined
> with a prototype or not.  The argument types should appear after the
> return types, each preceded by a semicolon, but for the following
> input program:
> 
>         int foo (int a, float b) { return a + b; }
> 
> `gcc -save-temps -O2 -g -c' generates the following relevant stabs:
> 
>     .stabs "int:t(0,1)=r(0,1);0020000000000;0017777777777;",128,0,0,0
>     .stabs "float:t(0,12)=r(0,1);4;0;",128,0,0,0
>     .stabs "foo:F(0,1)",36,0,1,foo
>     .stabs "a:P(0,1)",64,0,1,8
>     .stabs "b:P(0,12)",64,0,1,9
>     .stabs "",36,0,0,.LLscope0-foo
>             .stabs "",100,0,0,.Letext
> 
> There is no no prototype info here.  There's no way for GDB to know
> that the function expects its second argument to be passed as a float,
> not promoted to a double, as the K&R-style rules specify.

Yes, this is an old, old issue.  The test (float2) in callfuncs.exp
was designed to reveal this problem.  Unfortunately a few years ago
somebody went thru callfuncs.c and protoized all of the functions, 
thus defeating this test.  I've recently restored it, which is why
you may be suddenly seeing the fails again.


> 
> Thus:
> 
> 2001-11-26  Jim Blandy  <jimb@redhat.com>
> 
>         * gdb.base/callfuncs.exp: The stabs generated by GCC don't tell us
>         whether functions are prototyped or not, so we can't possibly pass
>         arguments to t_float_values2 properly.

Yep, that's why it's there.  I suppose xfailing it is reasonable, 
if there is no hope of it ever being fixed.


> 
> Index: gdb/testsuite/gdb.base/callfuncs.exp
> ===================================================================
> RCS file: /cvs/cvsfiles/devo/gdb/testsuite/gdb.base/callfuncs.exp,v
> retrieving revision 1.46
> diff -c -r1.46 callfuncs.exp
> *** gdb/testsuite/gdb.base/callfuncs.exp        2001/11/10 00:08:23     1.46
> --- gdb/testsuite/gdb.base/callfuncs.exp        2001/11/27 03:24:59
> ***************
> *** 142,147 ****
> --- 142,150 ----
>         gdb_test "p t_float_values(float_val1,-2.3765)" " = 1"
> 
>         # Test passing of arguments which might not be widened.
> +         # Under stabs, GCC doesn't tell us whether the function was
> +         # prototyped or not.
> +         if {$gcc_compiled} { setup_xfail_format "stabs" }
>         gdb_test "p t_float_values2(0.0,0.0)" " = 0"
> 
>         # Although PR 5318 mentions SunOS specifically, this seems
> ***************
> *** 152,158 ****
> --- 155,166 ----
>                 setup_xfail "alpha-dec-osf2*" "i*86-*-sysv4*" 5318
>             }
>         }
> +
> +         # Under stabs, GCC doesn't tell us whether the function was
> +         # prototyped or not.
> +         if {$gcc_compiled} { setup_xfail_format "stabs" }
>         gdb_test "p t_float_values2(3.14159,float_val2)" " = 1"
> +
>         gdb_test "p t_small_values(1,2,3,4,5,6,7,8,9,10)" " = 55"
> 
>         gdb_test "p t_double_values(0.0,0.0)" " = 0"
> ***************
> *** 289,294 ****
> --- 297,304 ----
>         }
>       }
>   }
> +
> + get_debug_format
> 
>   # Make sure that malloc gets called and that the floating point unit
>   # is initialized via a call to t_double_values.

Re: RFA: GCC stabs don't contain prototype info

[Michael Snyder]

Jim Blandy wrote:
> 
> This comes as a bit of a surprise to me, but it seems that stabs
> generated by GCC don't indicate whether a given function was defined
> with a prototype or not.  The argument types should appear after the
> return types, each preceded by a semicolon, but for the following
> input program:
> 
>         int foo (int a, float b) { return a + b; }
> 
> `gcc -save-temps -O2 -g -c' generates the following relevant stabs:
> 
>     .stabs "int:t(0,1)=r(0,1);0020000000000;0017777777777;",128,0,0,0
>     .stabs "float:t(0,12)=r(0,1);4;0;",128,0,0,0
>     .stabs "foo:F(0,1)",36,0,1,foo
>     .stabs "a:P(0,1)",64,0,1,8
>     .stabs "b:P(0,12)",64,0,1,9
>     .stabs "",36,0,0,.LLscope0-foo
>             .stabs "",100,0,0,.Letext
> 
> There is no no prototype info here.  There's no way for GDB to know
> that the function expects its second argument to be passed as a float,
> not promoted to a double, as the K&R-style rules specify.

Yes, this is an old, old issue.  The test (float2) in callfuncs.exp
was designed to reveal this problem.  Unfortunately a few years ago
somebody went thru callfuncs.c and protoized all of the functions, 
thus defeating this test.  I've recently restored it, which is why
you may be suddenly seeing the fails again.


> 
> Thus:
> 
> 2001-11-26  Jim Blandy  <jimb@redhat.com>
> 
>         * gdb.base/callfuncs.exp: The stabs generated by GCC don't tell us
>         whether functions are prototyped or not, so we can't possibly pass
>         arguments to t_float_values2 properly.

Yep, that's why it's there.  I suppose xfailing it is reasonable, 
if there is no hope of it ever being fixed.


> 
> Index: gdb/testsuite/gdb.base/callfuncs.exp
> ===================================================================
> RCS file: /cvs/cvsfiles/devo/gdb/testsuite/gdb.base/callfuncs.exp,v
> retrieving revision 1.46
> diff -c -r1.46 callfuncs.exp
> *** gdb/testsuite/gdb.base/callfuncs.exp        2001/11/10 00:08:23     1.46
> --- gdb/testsuite/gdb.base/callfuncs.exp        2001/11/27 03:24:59
> ***************
> *** 142,147 ****
> --- 142,150 ----
>         gdb_test "p t_float_values(float_val1,-2.3765)" " = 1"
> 
>         # Test passing of arguments which might not be widened.
> +         # Under stabs, GCC doesn't tell us whether the function was
> +         # prototyped or not.
> +         if {$gcc_compiled} { setup_xfail_format "stabs" }
>         gdb_test "p t_float_values2(0.0,0.0)" " = 0"
> 
>         # Although PR 5318 mentions SunOS specifically, this seems
> ***************
> *** 152,158 ****
> --- 155,166 ----
>                 setup_xfail "alpha-dec-osf2*" "i*86-*-sysv4*" 5318
>             }
>         }
> +
> +         # Under stabs, GCC doesn't tell us whether the function was
> +         # prototyped or not.
> +         if {$gcc_compiled} { setup_xfail_format "stabs" }
>         gdb_test "p t_float_values2(3.14159,float_val2)" " = 1"
> +
>         gdb_test "p t_small_values(1,2,3,4,5,6,7,8,9,10)" " = 55"
> 
>         gdb_test "p t_double_values(0.0,0.0)" " = 0"
> ***************
> *** 289,294 ****
> --- 297,304 ----
>         }
>       }
>   }
> +
> + get_debug_format
> 
>   # Make sure that malloc gets called and that the floating point unit
>   # is initialized via a call to t_double_values.

Re: RFA: GCC stabs don't contain prototype info

[Jim Blandy]

I've committed this change.

Jim Blandy <jimb@cygnus.com> writes:
> This comes as a bit of a surprise to me, but it seems that stabs
> generated by GCC don't indicate whether a given function was defined
> with a prototype or not.  The argument types should appear after the
> return types, each preceded by a semicolon, but for the following
> input program:
> 
>         int foo (int a, float b) { return a + b; }
> 
> `gcc -save-temps -O2 -g -c' generates the following relevant stabs:
> 
>     .stabs "int:t(0,1)=r(0,1);0020000000000;0017777777777;",128,0,0,0
>     .stabs "float:t(0,12)=r(0,1);4;0;",128,0,0,0
>     .stabs "foo:F(0,1)",36,0,1,foo
>     .stabs "a:P(0,1)",64,0,1,8
>     .stabs "b:P(0,12)",64,0,1,9
>     .stabs "",36,0,0,.LLscope0-foo
>             .stabs "",100,0,0,.Letext
> 
> There is no no prototype info here.  There's no way for GDB to know
> that the function expects its second argument to be passed as a float,
> not promoted to a double, as the K&R-style rules specify.
> 
> Thus:
> 
> 2001-11-26  Jim Blandy  <jimb@redhat.com>
> 
> 	* gdb.base/callfuncs.exp: The stabs generated by GCC don't tell us
> 	whether functions are prototyped or not, so we can't possibly pass
> 	arguments to t_float_values2 properly.
> 
> Index: gdb/testsuite/gdb.base/callfuncs.exp
> ===================================================================
> RCS file: /cvs/cvsfiles/devo/gdb/testsuite/gdb.base/callfuncs.exp,v
> retrieving revision 1.46
> diff -c -r1.46 callfuncs.exp
> *** gdb/testsuite/gdb.base/callfuncs.exp	2001/11/10 00:08:23	1.46
> --- gdb/testsuite/gdb.base/callfuncs.exp	2001/11/27 03:24:59
> ***************
> *** 142,147 ****
> --- 142,150 ----
>   	gdb_test "p t_float_values(float_val1,-2.3765)" " = 1"
>   
>   	# Test passing of arguments which might not be widened.
> +         # Under stabs, GCC doesn't tell us whether the function was
> +         # prototyped or not.
> +         if {$gcc_compiled} { setup_xfail_format "stabs" }
>   	gdb_test "p t_float_values2(0.0,0.0)" " = 0"
>   
>   	# Although PR 5318 mentions SunOS specifically, this seems
> ***************
> *** 152,158 ****
> --- 155,166 ----
>   		setup_xfail "alpha-dec-osf2*" "i*86-*-sysv4*" 5318
>   	    }
>   	}
> +         
> +         # Under stabs, GCC doesn't tell us whether the function was
> +         # prototyped or not.
> +         if {$gcc_compiled} { setup_xfail_format "stabs" }
>   	gdb_test "p t_float_values2(3.14159,float_val2)" " = 1"
> + 
>   	gdb_test "p t_small_values(1,2,3,4,5,6,7,8,9,10)" " = 55"
>   
>   	gdb_test "p t_double_values(0.0,0.0)" " = 0"
> ***************
> *** 289,294 ****
> --- 297,304 ----
>   	}
>       }
>   }
> + 
> + get_debug_format
>   
>   # Make sure that malloc gets called and that the floating point unit
>   # is initialized via a call to t_double_values.
>