RFA: MI tests: tolerate prototypes

RFA: MI tests: tolerate prototypes

[Jim Blandy]

Sun Feb  3 12:56:38 2002  Jim Blandy  <jimb@seadog.cygnus.com>

	* mi-var-child.exp ("get children of struct_declarations", "get
	children of struct_declarations.s2.u2.u1s2", "get children of
	weird"): Tolerate argument types when they appear in function
	types.  (Dwarf 2 includes prototype info; STABS does not.)
	* mi0-var-child.exp: Same.

Index: gdb/testsuite/gdb.mi/ChangeLog
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/testsuite/gdb.mi/ChangeLog,v
retrieving revision 1.3.24.2
diff -c -r1.3.24.2 ChangeLog
*** gdb/testsuite/gdb.mi/ChangeLog	2002/02/03 20:43:28	1.3.24.2
--- gdb/testsuite/gdb.mi/ChangeLog	2002/02/03 20:57:58
***************
*** 1,3 ****
--- 1,7 ----
+ Sun Feb  3 12:56:38 2002  Jim Blandy  <jimb@seadog.cygnus.com>
+ 
+ 	* mi-var-child.exp
+ 
  2002-02-02  Jim Blandy  <jimb@redhat.com>
  
  	* mi-regs.exp: Various cleanups for SPARC-only tests.
Index: gdb/testsuite/gdb.mi/mi-var-child.exp
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/testsuite/gdb.mi/mi-var-child.exp,v
retrieving revision 1.11
diff -c -r1.11 mi-var-child.exp
*** gdb/testsuite/gdb.mi/mi-var-child.exp	2001/08/20 19:06:07	1.11
--- gdb/testsuite/gdb.mi/mi-var-child.exp	2002/02/03 20:57:59
***************
*** 71,78 ****
  
  # Test: c_variable-4.3
  # Desc: children of struct_declarations
  mi_gdb_test "-var-list-children struct_declarations" \
! 	"\\^done,numchild=\"11\",children=\{child=\{name=\"struct_declarations.integer\",exp=\"integer\",numchild=\"0\",type=\"int\"\},child=\{name=\"struct_declarations.character\",exp=\"character\",numchild=\"0\",type=\"char\"\},child={name=\"struct_declarations.char_ptr\",exp=\"char_ptr\",numchild=\"1\",type=\"char \\*\"\},child=\{name=\"struct_declarations.long_int\",exp=\"long_int\",numchild=\"0\",type=\"long int\"\},child=\{name=\"struct_declarations.int_ptr_ptr\",exp=\"int_ptr_ptr\",numchild=\"1\",type=\"int \\*\\*\"\},child=\{name=\"struct_declarations.long_array\",exp=\"long_array\",numchild=\"10\",type=\"long int \\\[10\\\]\"\},child=\{name=\"struct_declarations.func_ptr\",exp=\"func_ptr\",numchild=\"0\",type=\"void \\(\\*\\)\\(\\)\"\},child=\{name=\"struct_declarations.func_ptr_struct\",exp=\"func_ptr_struct\",numchild=\"0\",type=\"struct _struct_decl \\(\\*\\)\\(\\)\"\},child=\{name=\"struct_declarations.func_ptr_ptr\",exp=\"func_ptr_ptr\",numchild=\"0\",type=\"struct _struct_decl \\*\\(\\*\\)\\(\\)\"\},child=\{name=\"struct_declarations.u1\",exp=\"u1\",numchild=\"4\",type=\"union \{\\.\\.\\.\}\"\},child=\{name=\"struct_declarations.s2\",exp=\"s2\",numchild=\"4\",type=\"struct \{\\.\\.\\.\}\"\}\}" \
  	"get children of struct_declarations"
  
  #gdbtk_test c_variable-4.3 {children of struct_declarations} {
--- 71,80 ----
  
  # Test: c_variable-4.3
  # Desc: children of struct_declarations
+ # STABS doesn't give us argument types for the func ptr structs, but
+ # Dwarf 2 does.
  mi_gdb_test "-var-list-children struct_declarations" \
! 	"\\^done,numchild=\"11\",children=\{child=\{name=\"struct_declarations.integer\",exp=\"integer\",numchild=\"0\",type=\"int\"\},child=\{name=\"struct_declarations.character\",exp=\"character\",numchild=\"0\",type=\"char\"\},child={name=\"struct_declarations.char_ptr\",exp=\"char_ptr\",numchild=\"1\",type=\"char \\*\"\},child=\{name=\"struct_declarations.long_int\",exp=\"long_int\",numchild=\"0\",type=\"long int\"\},child=\{name=\"struct_declarations.int_ptr_ptr\",exp=\"int_ptr_ptr\",numchild=\"1\",type=\"int \\*\\*\"\},child=\{name=\"struct_declarations.long_array\",exp=\"long_array\",numchild=\"10\",type=\"long int \\\[10\\\]\"\},child=\{name=\"struct_declarations.func_ptr\",exp=\"func_ptr\",numchild=\"0\",type=\"void \\(\\*\\)\\(\\)\"\},child=\{name=\"struct_declarations.func_ptr_struct\",exp=\"func_ptr_struct\",numchild=\"0\",type=\"struct _struct_decl \\(\\*\\)\\((int, char \\*, long int)?\\)\"\},child=\{name=\"struct_declarations.func_ptr_ptr\",exp=\"func_ptr_ptr\",numchild=\"0\",type=\"struct _struct_decl \\*\\(\\*\\)\\((int, char \\*, long int)?\\)\"\},child=\{name=\"struct_declarations.u1\",exp=\"u1\",numchild=\"4\",type=\"union \{\\.\\.\\.\}\"\},child=\{name=\"struct_declarations.s2\",exp=\"s2\",numchild=\"4\",type=\"struct \{\\.\\.\\.\}\"\}\}" \
  	"get children of struct_declarations"
  
  #gdbtk_test c_variable-4.3 {children of struct_declarations} {
***************
*** 466,472 ****
  # Test: c_variable-4.65
  # Desc: children of struct_declarations.s2.u2.u1s2
  mi_gdb_test "-var-list-children struct_declarations.s2.u2.u1s2" \
! 	"\\^done,numchild=\"2\",children=\{child=\{name=\"struct_declarations.s2.u2.u1s2.array_ptr\",exp=\"array_ptr\",numchild=\"2\",type=\"char \\\[2\\\]\"\},child=\{name=\"struct_declarations.s2.u2.u1s2.func\",exp=\"func\",numchild=\"0\",type=\"int \\(\\*\\)\\(\\)\"\}\}" \
  	"get children of struct_declarations.s2.u2.u1s2"
  
  # Test: c_variable-4.66
--- 468,474 ----
  # Test: c_variable-4.65
  # Desc: children of struct_declarations.s2.u2.u1s2
  mi_gdb_test "-var-list-children struct_declarations.s2.u2.u1s2" \
! 	"\\^done,numchild=\"2\",children=\{child=\{name=\"struct_declarations.s2.u2.u1s2.array_ptr\",exp=\"array_ptr\",numchild=\"2\",type=\"char \\\[2\\\]\"\},child=\{name=\"struct_declarations.s2.u2.u1s2.func\",exp=\"func\",numchild=\"0\",type=\"int \\(\\*\\)\\((int, char \\*)?\\)\"\}\}" \
  	"get children of struct_declarations.s2.u2.u1s2"
  
  # Test: c_variable-4.66
***************
*** 585,591 ****
  # Test: c_variable-4.82
  # Desc: children of weird
  mi_gdb_test "-var-list-children weird" \
! 	"\\^done,numchild=\"11\",children=\{child=\{name=\"weird.integer\",exp=\"integer\",numchild=\"0\",type=\"int\"\},child=\{name=\"weird.character\",exp=\"character\",numchild=\"0\",type=\"char\"\},child=\{name=\"weird.char_ptr\",exp=\"char_ptr\",numchild=\"1\",type=\"char \\*\"\},child=\{name=\"weird.long_int\",exp=\"long_int\",numchild=\"0\",type=\"long int\"\},child=\{name=\"weird.int_ptr_ptr\",exp=\"int_ptr_ptr\",numchild=\"1\",type=\"int \\*\\*\"\},child=\{name=\"weird.long_array\",exp=\"long_array\",numchild=\"10\",type=\"long int \\\[10\\\]\"\},child=\{name=\"weird.func_ptr\",exp=\"func_ptr\",numchild=\"0\",type=\"void \\(\\*\\)\\(\\)\"\},child=\{name=\"weird.func_ptr_struct\",exp=\"func_ptr_struct\",numchild=\"0\",type=\"struct _struct_decl \\(\\*\\)\\(\\)\"\},child=\{name=\"weird.func_ptr_ptr\",exp=\"func_ptr_ptr\",numchild=\"0\",type=\"struct _struct_decl \\*\\(\\*\\)\\(\\)\"\},child=\{name=\"weird.u1\",exp=\"u1\",numchild=\"4\",type=\"union \{\\.\\.\\.\}\"\},child=\{name=\"weird.s2\",exp=\"s2\",numchild=\"4\",type=\"struct \{\\.\\.\\.\}\"\}\}" \
  	"get children of weird"
  
  # Test: c_variable-4.83
--- 587,593 ----
  # Test: c_variable-4.82
  # Desc: children of weird
  mi_gdb_test "-var-list-children weird" \
! 	"\\^done,numchild=\"11\",children=\{child=\{name=\"weird.integer\",exp=\"integer\",numchild=\"0\",type=\"int\"\},child=\{name=\"weird.character\",exp=\"character\",numchild=\"0\",type=\"char\"\},child=\{name=\"weird.char_ptr\",exp=\"char_ptr\",numchild=\"1\",type=\"char \\*\"\},child=\{name=\"weird.long_int\",exp=\"long_int\",numchild=\"0\",type=\"long int\"\},child=\{name=\"weird.int_ptr_ptr\",exp=\"int_ptr_ptr\",numchild=\"1\",type=\"int \\*\\*\"\},child=\{name=\"weird.long_array\",exp=\"long_array\",numchild=\"10\",type=\"long int \\\[10\\\]\"\},child=\{name=\"weird.func_ptr\",exp=\"func_ptr\",numchild=\"0\",type=\"void \\(\\*\\)\\(\\)\"\},child=\{name=\"weird.func_ptr_struct\",exp=\"func_ptr_struct\",numchild=\"0\",type=\"struct _struct_decl \\(\\*\\)\\((int, char \\*, long int)?\\)\"\},child=\{name=\"weird.func_ptr_ptr\",exp=\"func_ptr_ptr\",numchild=\"0\",type=\"struct _struct_decl \\*\\(\\*\\)\\((int, char \\*, long int)?\\)\"\},child=\{name=\"weird.u1\",exp=\"u1\",numchild=\"4\",type=\"union \{\\.\\.\\.\}\"\},child=\{name=\"weird.s2\",exp=\"s2\",numchild=\"4\",type=\"struct \{\\.\\.\\.\}\"\}\}" \
  	"get children of weird"
  
  # Test: c_variable-4.83
Index: gdb/testsuite/gdb.mi/mi0-var-child.exp
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/testsuite/gdb.mi/mi0-var-child.exp,v
retrieving revision 1.2
diff -c -r1.2 mi0-var-child.exp
*** gdb/testsuite/gdb.mi/mi0-var-child.exp	2001/08/20 19:06:07	1.2
--- gdb/testsuite/gdb.mi/mi0-var-child.exp	2002/02/03 20:57:59
***************
*** 71,78 ****
  
  # Test: c_variable-4.3
  # Desc: children of struct_declarations
  mi_gdb_test "-var-list-children struct_declarations" \
! 	"\\^done,numchild=\"11\",children=\{child=\{name=\"struct_declarations.integer\",exp=\"integer\",numchild=\"0\",type=\"int\"\},child=\{name=\"struct_declarations.character\",exp=\"character\",numchild=\"0\",type=\"char\"\},child={name=\"struct_declarations.char_ptr\",exp=\"char_ptr\",numchild=\"1\",type=\"char \\*\"\},child=\{name=\"struct_declarations.long_int\",exp=\"long_int\",numchild=\"0\",type=\"long int\"\},child=\{name=\"struct_declarations.int_ptr_ptr\",exp=\"int_ptr_ptr\",numchild=\"1\",type=\"int \\*\\*\"\},child=\{name=\"struct_declarations.long_array\",exp=\"long_array\",numchild=\"10\",type=\"long int \\\[10\\\]\"\},child=\{name=\"struct_declarations.func_ptr\",exp=\"func_ptr\",numchild=\"0\",type=\"void \\(\\*\\)\\(\\)\"\},child=\{name=\"struct_declarations.func_ptr_struct\",exp=\"func_ptr_struct\",numchild=\"0\",type=\"struct _struct_decl \\(\\*\\)\\(\\)\"\},child=\{name=\"struct_declarations.func_ptr_ptr\",exp=\"func_ptr_ptr\",numchild=\"0\",type=\"struct _struct_decl \\*\\(\\*\\)\\(\\)\"\},child=\{name=\"struct_declarations.u1\",exp=\"u1\",numchild=\"4\",type=\"union \{\\.\\.\\.\}\"\},child=\{name=\"struct_declarations.s2\",exp=\"s2\",numchild=\"4\",type=\"struct \{\\.\\.\\.\}\"\}\}" \
  	"get children of struct_declarations"
  
  #gdbtk_test c_variable-4.3 {children of struct_declarations} {
--- 71,80 ----
  
  # Test: c_variable-4.3
  # Desc: children of struct_declarations
+ # STABS doesn't give us argument types for the func ptr structs, but
+ # Dwarf 2 does.
  mi_gdb_test "-var-list-children struct_declarations" \
! 	"\\^done,numchild=\"11\",children=\{child=\{name=\"struct_declarations.integer\",exp=\"integer\",numchild=\"0\",type=\"int\"\},child=\{name=\"struct_declarations.character\",exp=\"character\",numchild=\"0\",type=\"char\"\},child={name=\"struct_declarations.char_ptr\",exp=\"char_ptr\",numchild=\"1\",type=\"char \\*\"\},child=\{name=\"struct_declarations.long_int\",exp=\"long_int\",numchild=\"0\",type=\"long int\"\},child=\{name=\"struct_declarations.int_ptr_ptr\",exp=\"int_ptr_ptr\",numchild=\"1\",type=\"int \\*\\*\"\},child=\{name=\"struct_declarations.long_array\",exp=\"long_array\",numchild=\"10\",type=\"long int \\\[10\\\]\"\},child=\{name=\"struct_declarations.func_ptr\",exp=\"func_ptr\",numchild=\"0\",type=\"void \\(\\*\\)\\(\\)\"\},child=\{name=\"struct_declarations.func_ptr_struct\",exp=\"func_ptr_struct\",numchild=\"0\",type=\"struct _struct_decl \\(\\*\\)\\((int, char \\*, long int)?\\)\"\},child=\{name=\"struct_declarations.func_ptr_ptr\",exp=\"func_ptr_ptr\",numchild=\"0\",type=\"struct _struct_decl \\*\\(\\*\\)\\((int, char \\*, long int)?\\)\"\},child=\{name=\"struct_declarations.u1\",exp=\"u1\",numchild=\"4\",type=\"union \{\\.\\.\\.\}\"\},child=\{name=\"struct_declarations.s2\",exp=\"s2\",numchild=\"4\",type=\"struct \{\\.\\.\\.\}\"\}\}" \
  	"get children of struct_declarations"
  
  #gdbtk_test c_variable-4.3 {children of struct_declarations} {
***************
*** 466,472 ****
  # Test: c_variable-4.65
  # Desc: children of struct_declarations.s2.u2.u1s2
  mi_gdb_test "-var-list-children struct_declarations.s2.u2.u1s2" \
! 	"\\^done,numchild=\"2\",children=\{child=\{name=\"struct_declarations.s2.u2.u1s2.array_ptr\",exp=\"array_ptr\",numchild=\"2\",type=\"char \\\[2\\\]\"\},child=\{name=\"struct_declarations.s2.u2.u1s2.func\",exp=\"func\",numchild=\"0\",type=\"int \\(\\*\\)\\(\\)\"\}\}" \
  	"get children of struct_declarations.s2.u2.u1s2"
  
  # Test: c_variable-4.66
--- 468,474 ----
  # Test: c_variable-4.65
  # Desc: children of struct_declarations.s2.u2.u1s2
  mi_gdb_test "-var-list-children struct_declarations.s2.u2.u1s2" \
! 	"\\^done,numchild=\"2\",children=\{child=\{name=\"struct_declarations.s2.u2.u1s2.array_ptr\",exp=\"array_ptr\",numchild=\"2\",type=\"char \\\[2\\\]\"\},child=\{name=\"struct_declarations.s2.u2.u1s2.func\",exp=\"func\",numchild=\"0\",type=\"int \\(\\*\\)\\((int, char \\*)?\\)\"\}\}" \
  	"get children of struct_declarations.s2.u2.u1s2"
  
  # Test: c_variable-4.66
***************
*** 585,591 ****
  # Test: c_variable-4.82
  # Desc: children of weird
  mi_gdb_test "-var-list-children weird" \
! 	"\\^done,numchild=\"11\",children=\{child=\{name=\"weird.integer\",exp=\"integer\",numchild=\"0\",type=\"int\"\},child=\{name=\"weird.character\",exp=\"character\",numchild=\"0\",type=\"char\"\},child=\{name=\"weird.char_ptr\",exp=\"char_ptr\",numchild=\"1\",type=\"char \\*\"\},child=\{name=\"weird.long_int\",exp=\"long_int\",numchild=\"0\",type=\"long int\"\},child=\{name=\"weird.int_ptr_ptr\",exp=\"int_ptr_ptr\",numchild=\"1\",type=\"int \\*\\*\"\},child=\{name=\"weird.long_array\",exp=\"long_array\",numchild=\"10\",type=\"long int \\\[10\\\]\"\},child=\{name=\"weird.func_ptr\",exp=\"func_ptr\",numchild=\"0\",type=\"void \\(\\*\\)\\(\\)\"\},child=\{name=\"weird.func_ptr_struct\",exp=\"func_ptr_struct\",numchild=\"0\",type=\"struct _struct_decl \\(\\*\\)\\(\\)\"\},child=\{name=\"weird.func_ptr_ptr\",exp=\"func_ptr_ptr\",numchild=\"0\",type=\"struct _struct_decl \\*\\(\\*\\)\\(\\)\"\},child=\{name=\"weird.u1\",exp=\"u1\",numchild=\"4\",type=\"union \{\\.\\.\\.\}\"\},child=\{name=\"weird.s2\",exp=\"s2\",numchild=\"4\",type=\"struct \{\\.\\.\\.\}\"\}\}" \
  	"get children of weird"
  
  # Test: c_variable-4.83
--- 587,593 ----
  # Test: c_variable-4.82
  # Desc: children of weird
  mi_gdb_test "-var-list-children weird" \
! 	"\\^done,numchild=\"11\",children=\{child=\{name=\"weird.integer\",exp=\"integer\",numchild=\"0\",type=\"int\"\},child=\{name=\"weird.character\",exp=\"character\",numchild=\"0\",type=\"char\"\},child=\{name=\"weird.char_ptr\",exp=\"char_ptr\",numchild=\"1\",type=\"char \\*\"\},child=\{name=\"weird.long_int\",exp=\"long_int\",numchild=\"0\",type=\"long int\"\},child=\{name=\"weird.int_ptr_ptr\",exp=\"int_ptr_ptr\",numchild=\"1\",type=\"int \\*\\*\"\},child=\{name=\"weird.long_array\",exp=\"long_array\",numchild=\"10\",type=\"long int \\\[10\\\]\"\},child=\{name=\"weird.func_ptr\",exp=\"func_ptr\",numchild=\"0\",type=\"void \\(\\*\\)\\(\\)\"\},child=\{name=\"weird.func_ptr_struct\",exp=\"func_ptr_struct\",numchild=\"0\",type=\"struct _struct_decl \\(\\*\\)\\((int, char \\*, long int)?\\)\"\},child=\{name=\"weird.func_ptr_ptr\",exp=\"func_ptr_ptr\",numchild=\"0\",type=\"struct _struct_decl \\*\\(\\*\\)\\((int, char \\*, long int)?\\)\"\},child=\{name=\"weird.u1\",exp=\"u1\",numchild=\"4\",type=\"union \{\\.\\.\\.\}\"\},child=\{name=\"weird.s2\",exp=\"s2\",numchild=\"4\",type=\"struct \{\\.\\.\\.\}\"\}\}" \
  	"get children of weird"
  
  # Test: c_variable-4.83

Re: RFA: MI tests: tolerate prototypes

[Daniel Jacobowitz]

On Sun, Feb 03, 2002 at 04:06:09PM -0500, Jim Blandy wrote:
> 
> Sun Feb  3 12:56:38 2002  Jim Blandy  <jimb@seadog.cygnus.com>
> 
> 	* mi-var-child.exp ("get children of struct_declarations", "get
> 	children of struct_declarations.s2.u2.u1s2", "get children of
> 	weird"): Tolerate argument types when they appear in function
> 	types.  (Dwarf 2 includes prototype info; STABS does not.)
> 	* mi0-var-child.exp: Same.

Just out of curiousity... does the stabs information really not contain
this data, or are we just not recovering it?  Could you give an
example?

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

Re: RFA: MI tests: tolerate prototypes

[Andrew Cagney]

> Sun Feb  3 12:56:38 2002  Jim Blandy  <jimb@seadog.cygnus.com>
> 
> * mi-var-child.exp ("get children of struct_declarations", "get
> 	children of struct_declarations.s2.u2.u1s2", "get children of
> 	weird"): Tolerate argument types when they appear in function
> 	types.  (Dwarf 2 includes prototype info; STABS does not.)
> 	* mi0-var-child.exp: Same.
> 


Yes, thanks.  My mi test system uses stabs hence me not seeing this one.

Andrew

Re: RFA: MI tests: tolerate prototypes

[Jim Blandy]

Daniel Jacobowitz <drow@mvista.com> writes:
> On Sun, Feb 03, 2002 at 04:06:09PM -0500, Jim Blandy wrote:
> > 
> > Sun Feb  3 12:56:38 2002  Jim Blandy  <jimb@seadog.cygnus.com>
> > 
> > 	* mi-var-child.exp ("get children of struct_declarations", "get
> > 	children of struct_declarations.s2.u2.u1s2", "get children of
> > 	weird"): Tolerate argument types when they appear in function
> > 	types.  (Dwarf 2 includes prototype info; STABS does not.)
> > 	* mi0-var-child.exp: Same.
> 
> Just out of curiousity... does the stabs information really not contain
> this data, or are we just not recovering it?  Could you give an
> example?

It really doesn't contain it.  Check out the test program below.  Here
are the stabs for `prototyped_func' and `non_prototyped_func':

        .stabs  "prototyped_func:F(0,1)",36,0,3,prototyped_func
        .stabs  "f:p(0,14)",160,0,2,8
        .stabs  "s:p(0,1)",160,0,2,12
        .stabs  "s:(0,8)",128,0,2,-2
        .stabs  "",36,0,0,.Lscope0-prototyped_func

        .stabs  "non_prototyped_func:F(0,1)",36,0,11,non_prototyped_func
        .stabs  "f:p(0,15)",160,0,9,8
        .stabs  "s:p(0,1)",160,0,10,16
        .stabs  "f:(0,14)",128,0,9,-8
        .stabs  "s:(0,8)",128,0,10,-10
        .stabs  "",36,0,0,.Lscope1-non_prototyped_func

Notice that the types given in the functions' stabs are identical ---
`function returning int' --- even though one has type "prototyped
function returning int" and the other has type "non-prototyped
function returning int".

If you look at the stabs for the two function pointer variables, you
can see the problem even more easily:

        .stabs  "prototyped_fptr:G(0,23)=*(0,24)=f(0,1)",32,0,15,0
        .stabs  "non_prototyped_fptr:G(0,23)",32,0,16,0

The type info here for these functions is identical, even though you
couldn't even pass the `f' argument to (*prototyped_fptr) correctly
given this info.  (You'd pass a double, while it expects a float.)

It just so happens that almost every ABI tolerates smaller ints being
extended to full ints, so the problems aren't so bad there.  But
you'll still have problems passing ints to prototyped functions
expecting `long long' arguments, on machines where `long long' is
larger than `int'; you won't know that you need to promote them.

I was thinking that you could use the presence of the double stabs to
at least infer that a function was declared *without* a prototyped,
even if you couldn't use it to reliably detect those declared *with*
prototypes.  But look at the stabs for prototyped_func; it duplicates
the entry for 's', even though it's a prototyped function, and the
"passed-as" and "used-as" types are the same.

Anyway, there's a standard syntax for prototyped function types
defined in the STABS manual.  GDB even reads it.  If GCC would just
emit it, things would be better.


$ cat proto.c
int
prototyped_func (float f, short s)
{
  return f + s;
}

int
non_prototyped_func (f, s)
     float f;
     short s;
{
  return f + s;
}

int (*prototyped_fptr) (float f, short s);
int (*non_prototyped_fptr) (float f, short s);

int
baz (int i)
{
  return i;
}


int qux (i)
     int i;
{
  return i;
}
$ gcc -save-temps -g -c proto.c
$ cat proto.s
        .file   "proto.i"
        .stabs  "/home/jimb/gnupro/play/",100,0,0,.Ltext0
        .stabs  "proto.i",100,0,0,.Ltext0
        .text
.Ltext0:
        .stabs  "gcc2_compiled.",60,0,0,0
        .stabs  "int:t(0,1)=r(0,1);-2147483648;2147483647;",128,0,0,0
        .stabs  "char:t(0,2)=r(0,2);0;127;",128,0,0,0
        .stabs  "long int:t(0,3)=r(0,3);-2147483648;2147483647;",128,0,0,0
        .stabs  "unsigned int:t(0,4)=r(0,4);000000000000000000000000;000000000000037777777777;",128,0,0,0
        .stabs  "long unsigned int:t(0,5)=r(0,5);000000000000000000000000;000000000000037777777777;",128,0,0,0
        .stabs  "long long int:t(0,6)=@s64;r(0,6);001000000000000000000000;000777777777777777777777;",128,0,0,0
        .stabs  "long long unsigned int:t(0,7)=@s64;r(0,7);000000000000000000000000;001777777777777777777777;",128,0,0,0
        .stabs  "short int:t(0,8)=@s16;r(0,8);-32768;32767;",128,0,0,0
        .stabs  "short unsigned int:t(0,9)=@s16;r(0,9);0;65535;",128,0,0,0
        .stabs  "signed char:t(0,10)=@s8;r(0,10);-128;127;",128,0,0,0
        .stabs  "unsigned char:t(0,11)=@s8;r(0,11);0;255;",128,0,0,0
        .stabs  "__int128_t:t(0,12)=@s128;r(0,12);000000000000000000000000;0377777777777777777777777777777777;",128,0,0,0
        .stabs  "__uint128_t:t(0,13)=@s128;r(0,13);000000000000000000000000;0377777777777777777777777777777777;",128,0,0,0
        .stabs  "float:t(0,14)=r(0,1);4;0;",128,0,0,0
        .stabs  "double:t(0,15)=r(0,1);8;0;",128,0,0,0
        .stabs  "long double:t(0,16)=r(0,1);12;0;",128,0,0,0
        .stabs  "complex int:t(0,17)=s8real:(0,1),0,32;imag:(0,1),32,32;;",128,0,0,0
        .stabs  "complex float:t(0,18)=r(0,18);8;0;",128,0,0,0
        .stabs  "complex double:t(0,19)=r(0,19);16;0;",128,0,0,0
        .stabs  "complex long double:t(0,20)=r(0,20);24;0;",128,0,0,0
        .stabs  "__builtin_va_list:t(0,21)=*(0,2)",128,0,0,0
        .stabs  "_Bool:t(0,22)=@s8;-16;",128,0,0,0
        .align 2
        .stabs  "prototyped_func:F(0,1)",36,0,3,prototyped_func
        .stabs  "f:p(0,14)",160,0,2,8
        .stabs  "s:p(0,1)",160,0,2,12
.globl prototyped_func
        .type   prototyped_func,@function
prototyped_func:
        .stabs  "proto.c",132,0,0,.Ltext1
.Ltext1:
        .stabn 68,0,3,.LM1-prototyped_func
.LM1:
        pushl   %ebp
        movl    %esp, %ebp
        subl    $12, %esp
        movl    12(%ebp), %eax
        movw    %ax, -2(%ebp)
        .stabn 68,0,4,.LM2-prototyped_func
.LM2:
        filds   -2(%ebp)
        fadds   8(%ebp)
        fnstcw  -4(%ebp)
        movl    -4(%ebp), %eax
        orw     $3072, %ax
        movw    %ax, -6(%ebp)
        fldcw   -6(%ebp)
        fistpl  -12(%ebp)
        fldcw   -4(%ebp)
        movl    -12(%ebp), %eax
        .stabn 68,0,5,.LM3-prototyped_func
.LM3:
        leave
        ret
.Lfe1:
        .size   prototyped_func,.Lfe1-prototyped_func
        .stabs  "s:(0,8)",128,0,2,-2
.Lscope0:
        .stabs  "",36,0,0,.Lscope0-prototyped_func
        .align 2
        .stabs  "non_prototyped_func:F(0,1)",36,0,11,non_prototyped_func
        .stabs  "f:p(0,15)",160,0,9,8
        .stabs  "s:p(0,1)",160,0,10,16
.globl non_prototyped_func
        .type   non_prototyped_func,@function
non_prototyped_func:
        .stabn 68,0,11,.LM4-non_prototyped_func
.LM4:
        pushl   %ebp
        movl    %esp, %ebp
        subl    $20, %esp
        fldl    8(%ebp)
        movl    16(%ebp), %edx
        fstps   -4(%ebp)
        movl    -4(%ebp), %eax
        movl    %eax, -8(%ebp)
        movw    %dx, -10(%ebp)
        .stabn 68,0,12,.LM5-non_prototyped_func
.LM5:
        filds   -10(%ebp)
        fadds   -8(%ebp)
        fnstcw  -12(%ebp)
        movl    -12(%ebp), %eax
        orw     $3072, %ax
        movw    %ax, -14(%ebp)
        fldcw   -14(%ebp)
        fistpl  -20(%ebp)
        fldcw   -12(%ebp)
        movl    -20(%ebp), %eax
        .stabn 68,0,13,.LM6-non_prototyped_func
.LM6:
        leave
        ret
.Lfe2:
        .size   non_prototyped_func,.Lfe2-non_prototyped_func
        .stabs  "f:(0,14)",128,0,9,-8
        .stabs  "s:(0,8)",128,0,10,-10
.Lscope1:
        .stabs  "",36,0,0,.Lscope1-non_prototyped_func
        .align 2
        .stabs  "baz:F(0,1)",36,0,20,baz
        .stabs  "i:p(0,1)",160,0,19,8
.globl baz
        .type   baz,@function
baz:
        .stabn 68,0,20,.LM7-baz
.LM7:
        pushl   %ebp
        movl    %esp, %ebp
        .stabn 68,0,21,.LM8-baz
.LM8:
        movl    8(%ebp), %eax
        .stabn 68,0,22,.LM9-baz
.LM9:
        popl    %ebp
        ret
.Lfe3:
        .size   baz,.Lfe3-baz
.Lscope2:
        .stabs  "",36,0,0,.Lscope2-baz
        .align 2
        .stabs  "qux:F(0,1)",36,0,27,qux
        .stabs  "i:p(0,1)",160,0,26,8
.globl qux
        .type   qux,@function
qux:
        .stabn 68,0,27,.LM10-qux
.LM10:
        pushl   %ebp
        movl    %esp, %ebp
        .stabn 68,0,28,.LM11-qux
.LM11:
        movl    8(%ebp), %eax
        .stabn 68,0,29,.LM12-qux
.LM12:
        popl    %ebp
        ret
.Lfe4:
        .size   qux,.Lfe4-qux
.Lscope3:
        .stabs  "",36,0,0,.Lscope3-qux
        .comm   prototyped_fptr,4,4
        .comm   non_prototyped_fptr,4,4
        .stabs  "prototyped_fptr:G(0,23)=*(0,24)=f(0,1)",32,0,15,0
        .stabs  "non_prototyped_fptr:G(0,23)",32,0,16,0
        .text
        .stabs "",100,0,0,.Letext
.Letext:
        .ident  "GCC: (GNU) 3.1-gnupro-02r1"
$ 

Re: RFA: MI tests: tolerate prototypes

[Daniel Jacobowitz]

[Jason, the reason I CC'd you is down near the bottom.]

On Tue, Feb 05, 2002 at 06:56:04PM -0500, Jim Blandy wrote:
> 
> Daniel Jacobowitz <drow@mvista.com> writes:
> > On Sun, Feb 03, 2002 at 04:06:09PM -0500, Jim Blandy wrote:
> > > 
> > > Sun Feb  3 12:56:38 2002  Jim Blandy  <jimb@seadog.cygnus.com>
> > > 
> > > 	* mi-var-child.exp ("get children of struct_declarations", "get
> > > 	children of struct_declarations.s2.u2.u1s2", "get children of
> > > 	weird"): Tolerate argument types when they appear in function
> > > 	types.  (Dwarf 2 includes prototype info; STABS does not.)
> > > 	* mi0-var-child.exp: Same.
> > 
> > Just out of curiousity... does the stabs information really not contain
> > this data, or are we just not recovering it?  Could you give an
> > example?
> 
> It really doesn't contain it.  Check out the test program below.  Here
> are the stabs for `prototyped_func' and `non_prototyped_func':
> 
>         .stabs  "prototyped_func:F(0,1)",36,0,3,prototyped_func
>         .stabs  "f:p(0,14)",160,0,2,8
>         .stabs  "s:p(0,1)",160,0,2,12
>         .stabs  "s:(0,8)",128,0,2,-2
>         .stabs  "",36,0,0,.Lscope0-prototyped_func
> 
>         .stabs  "non_prototyped_func:F(0,1)",36,0,11,non_prototyped_func
>         .stabs  "f:p(0,15)",160,0,9,8
>         .stabs  "s:p(0,1)",160,0,10,16
>         .stabs  "f:(0,14)",128,0,9,-8
>         .stabs  "s:(0,8)",128,0,10,-10
>         .stabs  "",36,0,0,.Lscope1-non_prototyped_func
> 
> Notice that the types given in the functions' stabs are identical ---
> `function returning int' --- even though one has type "prototyped
> function returning int" and the other has type "non-prototyped
> function returning int".

Interestingly, for non_prototyped_func f is passed-as double and
used-as float.  We seem to record this.  Witness:

int func(float f, int s)
{ 
  return 1;
}

int func2 (f, s)
  float f;
  int s;
{ 
  return 2;
}

(gdb) ptype func
type = int (float, int)
(gdb) ptype func2
type = int (double, int)

I only see testsuite failures dealing with non-prototyped functions
because of DWARF-2.  GCC/Stabs marks non-prototyped functions as having the
post-promotion type; GCC/Dwarf-2 marks the real type of the function
and removes the DW_AT_prototyped attribute.

So it appears to me that the type of a function that we detect will be
the type-to-be-called-as for stabs.  For DWARF-2 it will be the
declared type, and we will have the DW_AT_prototyped attribute to tell
us if coercion is necessary.  I don't know how other debug readers will
behave, since those are the only two I'm familiar with.  Nor do I know
how Sun's compiler (for instance) emits stabs in this case - but the
stabs texinfo document suggests that it behaves the same.

We should be able to use this to get all cases right even without more
information.

> If you look at the stabs for the two function pointer variables, you
> can see the problem even more easily:
> 
>         .stabs  "prototyped_fptr:G(0,23)=*(0,24)=f(0,1)",32,0,15,0
>         .stabs  "non_prototyped_fptr:G(0,23)",32,0,16,0
> 
> The type info here for these functions is identical, even though you
> couldn't even pass the `f' argument to (*prototyped_fptr) correctly
> given this info.  (You'd pass a double, while it expects a float.)

How could you pass it at all?  That says 'function returning int'!  It
doesn't say what the arguments to the function are.

Also, your example says:
> int (*prototyped_fptr) (float f, short s);
> int (*non_prototyped_fptr) (float f, short s);

Of course those have the same types.  But even if you differentiate
them, stabs only describes function pointers by their return type. 
Quite regrettable; it must be a GCC bug or at least limitation.  This
is the one that's actually related to the patch at the start of this
thread.  I think that the patch is fine, but that this should go on our
list of things to fix in GCC's debug output.  Jason, I don't suppose
you could look at it?  The 'right' thing to do would be to emit the Sun
extension for any prototyped function or properly declared (prototyped,
essentially) function pointer.

> Anyway, there's a standard syntax for prototyped function types
> defined in the STABS manual.  GDB even reads it.  If GCC would just
> emit it, things would be better.

Yes, certainly.  But I think it should only cause cosmetic, not
functional, differences for functions.  For function pointers we need
more information but for functions we should have enough information to
call them correctly.

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

Re: RFA: MI tests: tolerate prototypes

[Jim Blandy]

Daniel Jacobowitz <drow@mvista.com> writes:
> I only see testsuite failures dealing with non-prototyped functions
> because of DWARF-2.  GCC/Stabs marks non-prototyped functions as having the
> post-promotion type; GCC/Dwarf-2 marks the real type of the function
> and removes the DW_AT_prototyped attribute.

Oh --- I never finished my TYPE_FLAG_MAYBE_PROTOTYPED changes.

GDB needs to distinguish between three kinds of function types:
- This function was declared K&R style.
- This function was declared with a prototype.
- We can't tell.

For STABS, we should produce the third kind, unless we see prototype
info, in which case we can produce the second.  For Dwarf 2, we only
ever produce the first two.

> So it appears to me that the type of a function that we detect will be
> the type-to-be-called-as for stabs.  For DWARF-2 it will be the
> declared type, and we will have the DW_AT_prototyped attribute to tell
> us if coercion is necessary.  I don't know how other debug readers will
> behave, since those are the only two I'm familiar with.  Nor do I know
> how Sun's compiler (for instance) emits stabs in this case - but the
> stabs texinfo document suggests that it behaves the same.
> 
> We should be able to use this to get all cases right even without more
> information.

Ah, by building `prototype'-style types for all the functions, even
those declared without prototypes, and using the called-as types as
the prototype argument types.  It'll work because, even though the
type claims to be prototyped, the argument types are such that we end
up doing the same promotions required by the rules for calling
non-prototyped functions.

> > If you look at the stabs for the two function pointer variables, you
> > can see the problem even more easily:
> > 
> >         .stabs  "prototyped_fptr:G(0,23)=*(0,24)=f(0,1)",32,0,15,0
> >         .stabs  "non_prototyped_fptr:G(0,23)",32,0,16,0
> > 
> > The type info here for these functions is identical, even though you
> > couldn't even pass the `f' argument to (*prototyped_fptr) correctly
> > given this info.  (You'd pass a double, while it expects a float.)
> 
> How could you pass it at all?  That says 'function returning int'!  It
> doesn't say what the arguments to the function are.

You pass them using the standard argument promotions, just as you
would if I had declared it

        int (*non_prototyped_fptr) ()

which is what I actually meant to type... duh.

> Also, your example says:
> > int (*prototyped_fptr) (float f, short s);
> > int (*non_prototyped_fptr) (float f, short s);
> 
> Of course those have the same types.  But even if you differentiate
> them, stabs only describes function pointers by their return type. 
> Quite regrettable; it must be a GCC bug or at least limitation.  This
> is the one that's actually related to the patch at the start of this
> thread.  I think that the patch is fine, but that this should go on our
> list of things to fix in GCC's debug output.  Jason, I don't suppose
> you could look at it?  The 'right' thing to do would be to emit the Sun
> extension for any prototyped function or properly declared (prototyped,
> essentially) function pointer.

Yes.

> > Anyway, there's a standard syntax for prototyped function types
> > defined in the STABS manual.  GDB even reads it.  If GCC would just
> > emit it, things would be better.
> 
> Yes, certainly.  But I think it should only cause cosmetic, not
> functional, differences for functions.  For function pointers we need
> more information but for functions we should have enough information to
> call them correctly.

Yes --- I didn't think so before, but I think you're right now.

Re: RFA: MI tests: tolerate prototypes

[Daniel Jacobowitz]

On Tue, Feb 05, 2002 at 11:32:22PM -0500, Jim Blandy wrote:
> 
> Daniel Jacobowitz <drow@mvista.com> writes:
> > I only see testsuite failures dealing with non-prototyped functions
> > because of DWARF-2.  GCC/Stabs marks non-prototyped functions as having the
> > post-promotion type; GCC/Dwarf-2 marks the real type of the function
> > and removes the DW_AT_prototyped attribute.
> 
> Oh --- I never finished my TYPE_FLAG_MAYBE_PROTOTYPED changes.
> 
> GDB needs to distinguish between three kinds of function types:
> - This function was declared K&R style.
> - This function was declared with a prototype.
> - We can't tell.
> 
> For STABS, we should produce the third kind, unless we see prototype
> info, in which case we can produce the second.  For Dwarf 2, we only
> ever produce the first two.
> 
> > So it appears to me that the type of a function that we detect will be
> > the type-to-be-called-as for stabs.  For DWARF-2 it will be the
> > declared type, and we will have the DW_AT_prototyped attribute to tell
> > us if coercion is necessary.  I don't know how other debug readers will
> > behave, since those are the only two I'm familiar with.  Nor do I know
> > how Sun's compiler (for instance) emits stabs in this case - but the
> > stabs texinfo document suggests that it behaves the same.
> > 
> > We should be able to use this to get all cases right even without more
> > information.
> 
> Ah, by building `prototype'-style types for all the functions, even
> those declared without prototypes, and using the called-as types as
> the prototype argument types.  It'll work because, even though the
> type claims to be prototyped, the argument types are such that we end
> up doing the same promotions required by the rules for calling
> non-prototyped functions.

So, the question becomes - do we need MAYBE_PROTOTYPED?  If we accept
that the types marked in stabs as parameters are promoted types, then
we can simply mark stabs functions as being prototyped, and trust
TYPE_FLAG_PROTOTYPED more than we do.

> > > If you look at the stabs for the two function pointer variables, you
> > > can see the problem even more easily:
> > > 
> > >         .stabs  "prototyped_fptr:G(0,23)=*(0,24)=f(0,1)",32,0,15,0
> > >         .stabs  "non_prototyped_fptr:G(0,23)",32,0,16,0
> > > 
> > > The type info here for these functions is identical, even though you
> > > couldn't even pass the `f' argument to (*prototyped_fptr) correctly
> > > given this info.  (You'd pass a double, while it expects a float.)
> > 
> > How could you pass it at all?  That says 'function returning int'!  It
> > doesn't say what the arguments to the function are.
> 
> You pass them using the standard argument promotions, just as you
> would if I had declared it
> 
>         int (*non_prototyped_fptr) ()
> 
> which is what I actually meant to type... duh.
> 
> > Also, your example says:
> > > int (*prototyped_fptr) (float f, short s);
> > > int (*non_prototyped_fptr) (float f, short s);
> > 
> > Of course those have the same types.  But even if you differentiate
> > them, stabs only describes function pointers by their return type. 
> > Quite regrettable; it must be a GCC bug or at least limitation.  This
> > is the one that's actually related to the patch at the start of this
> > thread.  I think that the patch is fine, but that this should go on our
> > list of things to fix in GCC's debug output.  Jason, I don't suppose
> > you could look at it?  The 'right' thing to do would be to emit the Sun
> > extension for any prototyped function or properly declared (prototyped,
> > essentially) function pointer.
> 
> Yes.
> 
> > > Anyway, there's a standard syntax for prototyped function types
> > > defined in the STABS manual.  GDB even reads it.  If GCC would just
> > > emit it, things would be better.
> > 
> > Yes, certainly.  But I think it should only cause cosmetic, not
> > functional, differences for functions.  For function pointers we need
> > more information but for functions we should have enough information to
> > call them correctly.
> 
> Yes --- I didn't think so before, but I think you're right now.
> 

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

Re: RFA: MI tests: tolerate prototypes

[Jim Blandy]

Daniel Jacobowitz <drow@mvista.com> writes:
> > Ah, by building `prototype'-style types for all the functions, even
> > those declared without prototypes, and using the called-as types as
> > the prototype argument types.  It'll work because, even though the
> > type claims to be prototyped, the argument types are such that we end
> > up doing the same promotions required by the rules for calling
> > non-prototyped functions.
> 
> So, the question becomes - do we need MAYBE_PROTOTYPED?  If we accept
> that the types marked in stabs as parameters are promoted types, then
> we can simply mark stabs functions as being prototyped, and trust
> TYPE_FLAG_PROTOTYPED more than we do.

If we do that, then:
- Dwarf 2 will continue to work correctly, since its prototype info
  has always been accurate,
- under STABS, calls to functions whose definitions we have debug info
  for will always work, unlike the current state of affairs, and 
- under STABS, calls via function pointers will do non-prototyped
  argument promotion, which is no worse than now.

Sounds good to me.

It does bother me, sort of on principle, that we won't really have
info about which functions were declared in which way.  I mean,
prototypedness is a real property of function types in ISO C.  But
given that our debug format doesn't carry the info we need, I guess
I'll just get over it. :)

Re: RFA: MI tests: tolerate prototypes

[Andrew Cagney]

> Daniel Jacobowitz <drow@mvista.com> writes:
> 
>> > Ah, by building `prototype'-style types for all the functions, even
>> > those declared without prototypes, and using the called-as types as
>> > the prototype argument types.  It'll work because, even though the
>> > type claims to be prototyped, the argument types are such that we end
>> > up doing the same promotions required by the rules for calling
>> > non-prototyped functions.
> 
>> 
>> So, the question becomes - do we need MAYBE_PROTOTYPED?  If we accept
>> that the types marked in stabs as parameters are promoted types, then
>> we can simply mark stabs functions as being prototyped, and trust
>> TYPE_FLAG_PROTOTYPED more than we do.
> 
> 
> If we do that, then:
> - Dwarf 2 will continue to work correctly, since its prototype info
>   has always been accurate,
> - under STABS, calls to functions whose definitions we have debug info
>   for will always work, unlike the current state of affairs, and 
> - under STABS, calls via function pointers will do non-prototyped
>   argument promotion, which is no worse than now.
> 
> Sounds good to me.
> 
> It does bother me, sort of on principle, that we won't really have
> info about which functions were declared in which way.  I mean,
> prototypedness is a real property of function types in ISO C.  But
> given that our debug format doesn't carry the info we need, I guess
> I'll just get over it. :)


Jim, my preference here is more along your proposal - have an explicit 
``prototype-unknown'' state.

 From memory the last time this came up I also suggested here that 
changing the default behavour across GDB is probably a good thing.  I 
don't think this is something that individual targets should be 
deciding.  Instead GDB should exibit consistent behavour across 
host/target combinations, the decision being made on the basis of the 
debug info.

enjoy,
Andrew

Re: RFA: MI tests: tolerate prototypes

[Daniel Jacobowitz]

On Wed, Feb 06, 2002 at 07:14:35PM -0500, Andrew Cagney wrote:
> >Daniel Jacobowitz <drow@mvista.com> writes:
> >
> >>> Ah, by building `prototype'-style types for all the functions, even
> >>> those declared without prototypes, and using the called-as types as
> >>> the prototype argument types.  It'll work because, even though the
> >>> type claims to be prototyped, the argument types are such that we end
> >>> up doing the same promotions required by the rules for calling
> >>> non-prototyped functions.
> >
> >>
> >>So, the question becomes - do we need MAYBE_PROTOTYPED?  If we accept
> >>that the types marked in stabs as parameters are promoted types, then
> >>we can simply mark stabs functions as being prototyped, and trust
> >>TYPE_FLAG_PROTOTYPED more than we do.
> >
> >
> >If we do that, then:
> >- Dwarf 2 will continue to work correctly, since its prototype info
> >  has always been accurate,
> >- under STABS, calls to functions whose definitions we have debug info
> >  for will always work, unlike the current state of affairs, and 
> >- under STABS, calls via function pointers will do non-prototyped
> >  argument promotion, which is no worse than now.
> >
> >Sounds good to me.
> >
> >It does bother me, sort of on principle, that we won't really have
> >info about which functions were declared in which way.  I mean,
> >prototypedness is a real property of function types in ISO C.  But
> >given that our debug format doesn't carry the info we need, I guess
> >I'll just get over it. :)
> 
> 
> Jim, my preference here is more along your proposal - have an explicit 
> ``prototype-unknown'' state.

I don't think we need it.  It seems that for at least stabs and DWARF-2
we have enough information to call the prototyped-ness known in all
cases.  In stabs we don't know if it is really prototyped or not, but
we know the called-as type, which is close enough to a prototype for
our purposes until debug info gets itself fixed.

> From memory the last time this came up I also suggested here that 
> changing the default behavour across GDB is probably a good thing.  I 
> don't think this is something that individual targets should be 
> deciding.  Instead GDB should exibit consistent behavour across 
> host/target combinations, the decision being made on the basis of the 
> debug info.

Certainly, it shouldn't be target-specific.  It depends only on the
debug format.

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

Re: RFA: MI tests: tolerate prototypes

[Jim Blandy]

> Jim, my preference here is more along your proposal - have an explicit
> ``prototype-unknown'' state.
> 
>  From memory the last time this came up I also suggested here that
> changing the default behavour across GDB is probably a good thing.  I
> don't think this is something that individual targets should be
> deciding.  Instead GDB should exibit consistent behavour across
> host/target combinations, the decision being made on the basis of the
> debug info.

Well, I wouldn't call it target-specific.  The compromise we're making
is more like this:

GCC's STABS describe prototyped function types as if they were
non-prototyped function types.  However, it does provide accurate
pass-as types for function definitions.  This means that GDB can
correctly call functions under STABS if it reads function definition
types *as if* they were prototyped, using the pass-as types as the
argument types.

The downsides of this proposal:

- GDB will print function argument types incorrectly.  For example, 
  suppose we have the following function definition:

     int f (short s, float f) { return s + f; }

  Since the arguments' pass-as types for `s' and `f' are `int' and
  `double', GDB will print f's type as `int f(int, double)'.  This is
  weird, but it's a direct consequence of lying about the type.
 
- Since GCC still doesn't really emit function types accurately, we
  won't always be able to correctly call pointed-to functions.  But
  this is true now, and the `maybe-prototyped' change wouldn't fix
  this either.

Re: RFA: MI tests: tolerate prototypes

[Daniel Jacobowitz]

On Thu, Feb 07, 2002 at 02:03:20PM -0500, Jim Blandy wrote:
> 
> > Jim, my preference here is more along your proposal - have an explicit
> > ``prototype-unknown'' state.
> > 
> >  From memory the last time this came up I also suggested here that
> > changing the default behavour across GDB is probably a good thing.  I
> > don't think this is something that individual targets should be
> > deciding.  Instead GDB should exibit consistent behavour across
> > host/target combinations, the decision being made on the basis of the
> > debug info.
> 
> Well, I wouldn't call it target-specific.  The compromise we're making
> is more like this:
> 
> GCC's STABS describe prototyped function types as if they were
> non-prototyped function types.  However, it does provide accurate
> pass-as types for function definitions.  This means that GDB can
> correctly call functions under STABS if it reads function definition
> types *as if* they were prototyped, using the pass-as types as the
> argument types.
> 
> The downsides of this proposal:
> 
> - GDB will print function argument types incorrectly.  For example, 
>   suppose we have the following function definition:
> 
>      int f (short s, float f) { return s + f; }
> 
>   Since the arguments' pass-as types for `s' and `f' are `int' and
>   `double', GDB will print f's type as `int f(int, double)'.  This is
>   weird, but it's a direct consequence of lying about the type.

Clarification: If f were not prototyped, this would be true.  So it's a
very small price to pay, IMHO.  If it is prototyped, the pass-as type
for f will be float, right?

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

function pointer stabs (was Re: RFA: MI tests: tolerate prototypes)

[Jason Merrill]

>>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:

> Of course those have the same types.  But even if you differentiate
> them, stabs only describes function pointers by their return type. 
> Quite regrettable; it must be a GCC bug or at least limitation.  This
> is the one that's actually related to the patch at the start of this
> thread.  I think that the patch is fine, but that this should go on our
> list of things to fix in GCC's debug output.  Jason, I don't suppose
> you could look at it?  The 'right' thing to do would be to emit the Sun
> extension for any prototyped function or properly declared (prototyped,
> essentially) function pointer.

>On Tue, Feb 05, 2002 at 06:56:04PM -0500, Jim Blandy wrote:

>> Anyway, there's a standard syntax for prototyped function types
>> defined in the STABS manual.  GDB even reads it.  If GCC would just
>> emit it, things would be better.

Looking at stabsread.c:read_type:case 'f', I don't see any support for
reading parameter types.

Also, the spec in stabs.texi seems to describe different extensions for
expressing parameters to actual functions versus function pointers.

Jason

Re: function pointer stabs (was Re: RFA: MI tests: tolerate prototypes)

[Daniel Jacobowitz]

On Fri, Feb 08, 2002 at 01:16:10PM +0000, Jason Merrill wrote:
> >>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:
> 
> > Of course those have the same types.  But even if you differentiate
> > them, stabs only describes function pointers by their return type. 
> > Quite regrettable; it must be a GCC bug or at least limitation.  This
> > is the one that's actually related to the patch at the start of this
> > thread.  I think that the patch is fine, but that this should go on our
> > list of things to fix in GCC's debug output.  Jason, I don't suppose
> > you could look at it?  The 'right' thing to do would be to emit the Sun
> > extension for any prototyped function or properly declared (prototyped,
> > essentially) function pointer.
> 
> >On Tue, Feb 05, 2002 at 06:56:04PM -0500, Jim Blandy wrote:
> 
> >> Anyway, there's a standard syntax for prototyped function types
> >> defined in the STABS manual.  GDB even reads it.  If GCC would just
> >> emit it, things would be better.
> 
> Looking at stabsread.c:read_type:case 'f', I don't see any support for
> reading parameter types.

For function definitions, it's in define_symbol.  First it falls in to
process_function_types, then into process_prototype_types, where it
checks:
      /* Sun acc puts declared types of arguments here.  */
      if (*p == ';')
But the only thing we need that information for AFAIK is curiousity. 
We don't really need to know if the function was originally prototyped
if we know how it should be called.

For function TYPES, there's vestigial support for ignoring an os9k
prototype, but no support for the Sun prototypes.  I stand corrected.
Should we add this, or write it off?

> Also, the spec in stabs.texi seems to describe different extensions for
> expressing parameters to actual functions versus function pointers.

Hmm, yes, I had not seen that.

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

Re: RFA: MI tests: tolerate prototypes

[Jim Blandy]

Daniel Jacobowitz <drow@mvista.com> writes:
> > GCC's STABS describe prototyped function types as if they were
> > non-prototyped function types.  However, it does provide accurate
> > pass-as types for function definitions.  This means that GDB can
> > correctly call functions under STABS if it reads function definition
> > types *as if* they were prototyped, using the pass-as types as the
> > argument types.
> > 
> > The downsides of this proposal:
> > 
> > - GDB will print function argument types incorrectly.  For example, 
> >   suppose we have the following function definition:
> > 
> >      int f (short s, float f) { return s + f; }
> > 
> >   Since the arguments' pass-as types for `s' and `f' are `int' and
> >   `double', GDB will print f's type as `int f(int, double)'.  This is
> >   weird, but it's a direct consequence of lying about the type.
> 
> Clarification: If f were not prototyped, this would be true.  So it's a
> very small price to pay, IMHO.  If it is prototyped, the pass-as type
> for f will be float, right?

Jeez, it's not like this isn't confusing enough already without my
consistently writing the opposite of what I mean.  I meant to write:

        int f (s, f) short s; float f; { return s + f; }

That function will end up with pass-as types of `int' and `double', as
required by C's rules (which are not target-specific).  It will have
use-as types of `short' and `float'.  Seeing an apparently
unprototyped function definition in STABS, GDB would (under the
proposal) construct a prototyped type with `int' and `double' as its
argument types.

The drawback here is that GDB will print the function's type as `int f
(int, double)', instead of the more correct `int f ()'.  The benefit
is that GDB will be able to call all functions for which it can find
definitions correctly --- a benefit which my `maybe-prototyped'
proposal doesn't offer.

Re: function pointer stabs (was Re: RFA: MI tests: tolerate prototypes)

[Jim Blandy]

Daniel Jacobowitz <drow@mvista.com> writes:
> But the only thing we need that information for AFAIK is curiousity. 
> We don't really need to know if the function was originally prototyped
> if we know how it should be called.

Remember, we can only glean that info from *definitions*.  We don't
have it for function pointers.

> For function TYPES, there's vestigial support for ignoring an os9k
> prototype, but no support for the Sun prototypes.  I stand corrected.
> Should we add this, or write it off?

Oif!  Let's add it.  It can't be that hard.

Re: function pointer stabs (was Re: RFA: MI tests: tolerate prototypes)

[Jim Blandy]

I've been looking at Sun's STABS manual, which seems to only be
available from:
http://www.cs.ucsb.edu/facilities/software/cc-info/stabs.ps

That manual suggests that Sun's compiler emits an N_FUN stab of the
form:

    .stabs "foo:F<returntype>;<argtype>;<argtype>;..."

even for non-prototyped functions.  So the presence of argument types
separated by semicolons still doesn't reliably tell us that the
function was defined in prototype form, as I (and apparently
stabsread.c) assumed it did.  It seems to me that this duplicates the
information provided by the N_RSYM and N_PSYM stabs.  Whatever.

GDB parses this form already.  We just need to be aware that its
presence does *not* mean "This function was declared in prototype
form."

For types, Sun emits the 'f' type descriptor for unprototyped function
types, and the 'g' type descriptor for prototyped function types.  The
form seems to be:

        "g" RETURN-TYPE ARGUMENT-TYPE * "#"

The examples in the manual are:

  int (*fptr) (int, float)
  .stabs "fptr:G(0,21)=*(0,22)=g(0,3)(0,3)(0,17)#"

  The second (0,3) is for first argument int, and (0,17) is for second
  argument float. [sic]  More examples:

  typedef int (*func_type) (int (*) (int, float), float);
  struct a {
    int x;
    my_type* (*fptr1) (int (*) (int, float), float);        
    char y;
  };
  int (*xptr) (int (*) (), int (*) (void), int);
  // Note int(*)() is function with unknown parameter types

  .stabs "func_type:t(0,22)=*(0,23)=g(0,3)(0,50)=*(0,51)=
          g(0,3)(0,3)(0,17)#(0,17)#",
          N_LSYM,0x0,0x4,0x40
  .stabs "a:T(0,24)=s12x:(0,3),0,32;fptr1:(0,25)=*(0,26)=g(0,27)=
          *(0,3)(0,40)=*(0,41)=g(0,3)(0,3)(0,17)#(0,17)#,32,32;y:(0,1),64,8;;",
          N_LSYM,0x0,0xc,0x1
  .stabs "xptr:G(0,28)=*(0,29)=g(0,3)(0,60)=*(0,61)=f(0,3)(0,62)=*(0,63)=
          g(0,3)(0,20)#(0,3)#",N_GSYM,0x0,0x4,0x0

But in this case, 'f' really does mean "non-prototyped function", and
'g' really does mean "prototyped function."  So we can get accurate
information here.

I'd be happy if someone would double-check my reading.

Re: function pointer stabs (was Re: RFA: MI tests: tolerate prototypes)

[Jim Blandy]

All right --- I've committed a change to allow GDB to read Sun-style
prototyped function types, and I've posted tests for it, which
hopefully will be approved soon.  So it's you GCC guys' turn to teach
GCC to emit those, now that you have a GDB you can test against.

The format is documented in:
http://www.cs.ucsb.edu/facilities/software/cc-info/stabs.ps

Also, the test case includes examples of the sort of STABS GDB expects
to see:

/**** Pointers to functions *******/

typedef int (*func_type) (int (*) (int, float), float);
double (*old_fptr) ();
double (*new_fptr) (void);
int (*fptr) (int, float);
int *(*fptr2) (int (*) (int, float), float);
int (*xptr) (int (*) (), int (*) (void), int);
int (*(*ffptr) (char)) (short);
int (*(*(*fffptr) (char)) (short)) (long);

/* Here are the sort of stabs we expect to see for the above:

   .stabs "func_type:t(0,100)=*(0,101)=g(0,1)(0,102)=*(0,103)=g(0,1)(0,1)(0,14)#(0,14)#",128,0,234,0
   .stabs "old_fptr:G(0,110)=*(0,111)=f(0,15)",32,0,231,0
   .stabs "new_fptr:G(0,120)=*(0,121)=g(0,15)(0,122)=(0,122)#",32,0,232,0
   .stabs "fptr:G(0,130)=*(0,103)#",32,0,233,0
   .stabs "fptr2:G(0,140)=*(0,141)=g(0,142)=*(0,1)(0,102)(0,14)#",32,0,235,0
   .stabs "xptr:G(0,150)=*(0,151)=g(0,1)(0,152)=*(0,153)=f(0,1)(0,154)=*(0,155)=g(0,1)(0,122)#(0,1)#",32,0,236,0
   .stabs "ffptr:G(0,160)=*(0,161)=g(0,162)=*(0,163)=g(0,1)(0,8)#(0,2)#",32,0,237,0\
   .stabs "fffptr:G(0,170)=*(0,171)=g(0,172)=*(0,173)=g(0,174)=*(0,175)=g(0,1)(0,3)#(0,8)#(0,2)#",32,0,237,0

   Most of these use Sun's extension for prototyped function types ---
   the 'g' type descriptor.  As of around 9 Feb 2002, GCC didn't emit
   those, but GDB can read them, so the related tests in ptype.exp
   will all xfail.  */

Re: function pointer stabs (was Re: RFA: MI tests: tolerate prototypes)

[Daniel Jacobowitz]

On Sat, Feb 09, 2002 at 03:16:56PM -0500, Jim Blandy wrote:
> 
> All right --- I've committed a change to allow GDB to read Sun-style
> prototyped function types, and I've posted tests for it, which
> hopefully will be approved soon.  So it's you GCC guys' turn to teach
> GCC to emit those, now that you have a GDB you can test against.
> 
> The format is documented in:
> http://www.cs.ucsb.edu/facilities/software/cc-info/stabs.ps
> 
> Also, the test case includes examples of the sort of STABS GDB expects
> to see:
> 
> /**** Pointers to functions *******/
> 
> typedef int (*func_type) (int (*) (int, float), float);
> double (*old_fptr) ();
> double (*new_fptr) (void);
> int (*fptr) (int, float);
> int *(*fptr2) (int (*) (int, float), float);
> int (*xptr) (int (*) (), int (*) (void), int);
> int (*(*ffptr) (char)) (short);
> int (*(*(*fffptr) (char)) (short)) (long);
> 
> /* Here are the sort of stabs we expect to see for the above:
> 
>    .stabs "func_type:t(0,100)=*(0,101)=g(0,1)(0,102)=*(0,103)=g(0,1)(0,1)(0,14)#(0,14)#",128,0,234,0
>    .stabs "old_fptr:G(0,110)=*(0,111)=f(0,15)",32,0,231,0
>    .stabs "new_fptr:G(0,120)=*(0,121)=g(0,15)(0,122)=(0,122)#",32,0,232,0
>    .stabs "fptr:G(0,130)=*(0,103)#",32,0,233,0
>    .stabs "fptr2:G(0,140)=*(0,141)=g(0,142)=*(0,1)(0,102)(0,14)#",32,0,235,0
>    .stabs "xptr:G(0,150)=*(0,151)=g(0,1)(0,152)=*(0,153)=f(0,1)(0,154)=*(0,155)=g(0,1)(0,122)#(0,1)#",32,0,236,0
>    .stabs "ffptr:G(0,160)=*(0,161)=g(0,162)=*(0,163)=g(0,1)(0,8)#(0,2)#",32,0,237,0\
>    .stabs "fffptr:G(0,170)=*(0,171)=g(0,172)=*(0,173)=g(0,174)=*(0,175)=g(0,1)(0,3)#(0,8)#(0,2)#",32,0,237,0
> 
>    Most of these use Sun's extension for prototyped function types ---
>    the 'g' type descriptor.  As of around 9 Feb 2002, GCC didn't emit
>    those, but GDB can read them, so the related tests in ptype.exp
>    will all xfail.  */

Have you ever seen these generated?  I'm fairly certain about two
things:
  - I couldn't get Sun Workshop 6 to generate 'g' stabs
  - I'm slightly concerned about the types not separated by anything. 
Some compilers use non-tuple types... read_type should behave OK,
though.


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