Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* RFA: GCC stabs don't contain prototype info
  2001-11-26 19:43 RFA: GCC stabs don't contain prototype info Jim Blandy
@ 2001-11-13 10:56 ` Jim Blandy
  2001-11-26 19:47 ` Daniel Jacobowitz
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 15+ messages in thread
From: Jim Blandy @ 2001-11-13 10:56 UTC (permalink / raw)
  To: gdb-patches


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.


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

* Re: RFA: GCC stabs don't contain prototype info
  2001-11-26 19:47 ` Daniel Jacobowitz
@ 2001-11-13 11:07   ` Daniel Jacobowitz
  2001-11-26 20:19   ` Jim Blandy
  1 sibling, 0 replies; 15+ messages in thread
From: Daniel Jacobowitz @ 2001-11-13 11:07 UTC (permalink / raw)
  To: gdb-patches

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


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

* Re: RFA: GCC stabs don't contain prototype info
  2001-11-26 20:19   ` Jim Blandy
@ 2001-11-13 15:38     ` Jim Blandy
  2001-11-27 14:16     ` Michael Snyder
  1 sibling, 0 replies; 15+ messages in thread
From: Jim Blandy @ 2001-11-13 15:38 UTC (permalink / raw)
  To: Daniel Jacobowitz; +Cc: gdb-patches


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.)


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

* Re: RFA: GCC stabs don't contain prototype info
  2001-11-27 14:10 ` Michael Snyder
@ 2001-11-15  2:38   ` Michael Snyder
  0 siblings, 0 replies; 15+ messages in thread
From: Michael Snyder @ 2001-11-15  2:38 UTC (permalink / raw)
  To: Jim Blandy; +Cc: gdb-patches

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.


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

* Re: RFA: GCC stabs don't contain prototype info
  2001-11-27 14:16     ` Michael Snyder
@ 2001-11-15  7:01       ` Michael Snyder
  2001-11-15  8:00       ` Daniel Berlin
  1 sibling, 0 replies; 15+ messages in thread
From: Michael Snyder @ 2001-11-15  7:01 UTC (permalink / raw)
  To: Jim Blandy; +Cc: Daniel Jacobowitz, gdb-patches

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.


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

* Re: RFA: GCC stabs don't contain prototype info
  2001-11-27 14:16     ` Michael Snyder
  2001-11-15  7:01       ` Michael Snyder
@ 2001-11-15  8:00       ` Daniel Berlin
  2001-11-27 14:27         ` Daniel Berlin
  2001-11-27 20:49         ` Jim Blandy
  1 sibling, 2 replies; 15+ messages in thread
From: Daniel Berlin @ 2001-11-15  8:00 UTC (permalink / raw)
  To: Michael Snyder; +Cc: Jim Blandy, Daniel Jacobowitz, gdb-patches



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.
>


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

* Re: RFA: GCC stabs don't contain prototype info
  2001-11-27 20:49         ` Jim Blandy
@ 2001-11-16 10:45           ` Jim Blandy
  0 siblings, 0 replies; 15+ messages in thread
From: Jim Blandy @ 2001-11-16 10:45 UTC (permalink / raw)
  To: Daniel Berlin; +Cc: Michael Snyder, Daniel Jacobowitz, gdb-patches


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*


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

* RFA: GCC stabs don't contain prototype info
@ 2001-11-26 19:43 Jim Blandy
  2001-11-13 10:56 ` Jim Blandy
                   ` (3 more replies)
  0 siblings, 4 replies; 15+ messages in thread
From: Jim Blandy @ 2001-11-26 19:43 UTC (permalink / raw)
  To: gdb-patches

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.


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

* Re: RFA: GCC stabs don't contain prototype info
  2001-11-26 19:43 RFA: GCC stabs don't contain prototype info Jim Blandy
  2001-11-13 10:56 ` Jim Blandy
@ 2001-11-26 19:47 ` Daniel Jacobowitz
  2001-11-13 11:07   ` Daniel Jacobowitz
  2001-11-26 20:19   ` Jim Blandy
  2001-11-27 14:10 ` Michael Snyder
  2001-12-07 13:17 ` Jim Blandy
  3 siblings, 2 replies; 15+ messages in thread
From: Daniel Jacobowitz @ 2001-11-26 19:47 UTC (permalink / raw)
  To: gdb-patches

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


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

* Re: RFA: GCC stabs don't contain prototype info
  2001-11-26 19:47 ` Daniel Jacobowitz
  2001-11-13 11:07   ` Daniel Jacobowitz
@ 2001-11-26 20:19   ` Jim Blandy
  2001-11-13 15:38     ` Jim Blandy
  2001-11-27 14:16     ` Michael Snyder
  1 sibling, 2 replies; 15+ messages in thread
From: Jim Blandy @ 2001-11-26 20:19 UTC (permalink / raw)
  To: Daniel Jacobowitz; +Cc: gdb-patches

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.)


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

* Re: RFA: GCC stabs don't contain prototype info
  2001-11-26 19:43 RFA: GCC stabs don't contain prototype info Jim Blandy
  2001-11-13 10:56 ` Jim Blandy
  2001-11-26 19:47 ` Daniel Jacobowitz
@ 2001-11-27 14:10 ` Michael Snyder
  2001-11-15  2:38   ` Michael Snyder
  2001-12-07 13:17 ` Jim Blandy
  3 siblings, 1 reply; 15+ messages in thread
From: Michael Snyder @ 2001-11-27 14:10 UTC (permalink / raw)
  To: Jim Blandy; +Cc: gdb-patches

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.


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

* Re: RFA: GCC stabs don't contain prototype info
  2001-11-26 20:19   ` Jim Blandy
  2001-11-13 15:38     ` Jim Blandy
@ 2001-11-27 14:16     ` Michael Snyder
  2001-11-15  7:01       ` Michael Snyder
  2001-11-15  8:00       ` Daniel Berlin
  1 sibling, 2 replies; 15+ messages in thread
From: Michael Snyder @ 2001-11-27 14:16 UTC (permalink / raw)
  To: Jim Blandy; +Cc: Daniel Jacobowitz, gdb-patches

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.


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

* Re: RFA: GCC stabs don't contain prototype info
  2001-11-15  8:00       ` Daniel Berlin
@ 2001-11-27 14:27         ` Daniel Berlin
  2001-11-27 20:49         ` Jim Blandy
  1 sibling, 0 replies; 15+ messages in thread
From: Daniel Berlin @ 2001-11-27 14:27 UTC (permalink / raw)
  To: Michael Snyder; +Cc: Jim Blandy, Daniel Jacobowitz, gdb-patches

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.
>


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

* Re: RFA: GCC stabs don't contain prototype info
  2001-11-15  8:00       ` Daniel Berlin
  2001-11-27 14:27         ` Daniel Berlin
@ 2001-11-27 20:49         ` Jim Blandy
  2001-11-16 10:45           ` Jim Blandy
  1 sibling, 1 reply; 15+ messages in thread
From: Jim Blandy @ 2001-11-27 20:49 UTC (permalink / raw)
  To: Daniel Berlin; +Cc: Michael Snyder, Daniel Jacobowitz, gdb-patches

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*


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

* Re: RFA: GCC stabs don't contain prototype info
  2001-11-26 19:43 RFA: GCC stabs don't contain prototype info Jim Blandy
                   ` (2 preceding siblings ...)
  2001-11-27 14:10 ` Michael Snyder
@ 2001-12-07 13:17 ` Jim Blandy
  3 siblings, 0 replies; 15+ messages in thread
From: Jim Blandy @ 2001-12-07 13:17 UTC (permalink / raw)
  To: gdb-patches

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.
> 


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

end of thread, other threads:[~2001-12-07 21:17 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-11-26 19:43 RFA: GCC stabs don't contain prototype info Jim Blandy
2001-11-13 10:56 ` Jim Blandy
2001-11-26 19:47 ` Daniel Jacobowitz
2001-11-13 11:07   ` Daniel Jacobowitz
2001-11-26 20:19   ` Jim Blandy
2001-11-13 15:38     ` Jim Blandy
2001-11-27 14:16     ` Michael Snyder
2001-11-15  7:01       ` Michael Snyder
2001-11-15  8:00       ` Daniel Berlin
2001-11-27 14:27         ` Daniel Berlin
2001-11-27 20:49         ` Jim Blandy
2001-11-16 10:45           ` Jim Blandy
2001-11-27 14:10 ` Michael Snyder
2001-11-15  2:38   ` Michael Snyder
2001-12-07 13:17 ` Jim Blandy

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