Re: Fwd: Two possible function stabs patches

Re: Fwd: Two possible function stabs patches

[Michael Elizabeth Chastain]

First patch:

  no regressions in gdb test suite output
  no improvements, either
  native i686-pc-linux-gnu
  red hat linux 8
  binutils 2.14
  -gstabs+

Second patch:

  still running ...

My test bed deletes the build directories for gcc after it builds
each gcc, so I got to do a little extra build-from-scratch
this evening.  Argh.

Michael C

Re: Two possible function stabs patches

[Geoffrey Keating]

[This might be a duplicate, in which case please ignore it...]

On Tuesday, July 29, 2003, at 10:47  PM, Michael Elizabeth Chastain 
wrote:

> First patch:
>
>   no regressions in gdb test suite output
>   no improvements, either
>   native i686-pc-linux-gnu
>   red hat linux 8
>   binutils 2.14
>   -gstabs+

Excellent!  Except, that probably means that the gdb testsuite could do 
with some more testcases.  Is there a GDB person who could add the one 
I mentioned earlier,

int main(void)
{
   static int foo(void)  { return 1; }
   return foo() == 1 ? 0 : 1;
}

break foo

?

> Second patch:
>
>   still running ...
>
> My test bed deletes the build directories for gcc after it builds
> each gcc, so I got to do a little extra build-from-scratch
> this evening.  Argh.
>
Thank you for all your work!

Re: Fwd: Two possible function stabs patches

[Michael Elizabeth Chastain]

The results are in and patch #2 choked gdb (as Daniel J predicted).

Regressions in:

  gdb.c++/anon-union.exp
  gdb.c++/classes.exp
  gdb.c++/cplusfuncs.exp
  gdb.c++/derivation.exp
  gdb.c++/local.exp
  gdb.c++/m-data.exp
  gdb.c++/method.exp
  gdb.c++/misc.exp
  gdb.c++/namespace.exp
  gdb.c++/overload.exp
  gdb.c++/ovldbreak.exp
  gdb.c++/pr-1023.exp
  gdb.c++/pr-1210.exp
  gdb.c++/printmethod.exp
  gdb.c++/psmang.exp
  gdb.c++/templates.exp
  gdb.c++/try_catch.exp
  gdb.c++/userdef.exp
  gdb.mi/gdb792.exp
  gdb.objc/basicclass.exp

That's in gdb gdb_6_0-branch.  Similar regressions with gdb 5.3
and gdb HEAD.

Michael C

Re: Fwd: Two possible function stabs patches

[Andrew Cagney]

> Oops!  Forgot to attach the actual patches.  Fixed below.
> 
> 
> OK, so I have not one, but two patches!

Um, these appear to come with a little history (Solaris perhaphs?).  Can 
you provide a bit of a background?  You'll likely also want to add 
something to the GNU stabs document found in the GDB distro.

> The first one is less interesting.  It uses the language's name for the function, unless it's a C++ function, in which case it uses the (mangled) assembler name.  It'll give a stab like
> 
>         .stabs  "__ZN3bar3fooEv:F(0,1)",36,0,2,__ZN3bar3fooEv
> or
>         .stabs  "foo:F(0,1)",36,0,2,foo.11
> 
> The second one uses the 'printable name' for the function.  That is, for C it's just the name, and for C++ it's the demangled version of its name.  I am not at all sure it'll work, because it gives stabs like:
> 
>         .stabs  "int bar::foo():F(0,1)",36,0,2,__ZN3bar3fooEv
> 
> which I suspect can't be parsed.
> 
> Could someone help me test these?  It needs a machine that can use stabs and on which the GDB testsuite doesn't give too many false positives. 

I'd strongly encourage you to install GNU/Linux and *BSD on a couple 
local old/slow Mac boxes.  It will make testing a lot easier.

enjoy,
Andrew

Re: Fwd: Two possible function stabs patches

[Michael Elizabeth Chastain]

Geoff> Could someone help me test these?  It needs a machine that can use 
Geoff> stabs and on which the GDB testsuite doesn't give too many false 
Geoff> positives.

Two test runs coming up!

I'm going to presume that these are insensitive to the binutils
version and just use binutils 2.14 (as opposed to the ensemble
of four different binutils).  Daniel J, that is a safe assumption,
right?

Michael C

Re: Fwd: Two possible function stabs patches

[Daniel Jacobowitz]

On Tue, Jul 29, 2003 at 06:07:15PM -0700, Geoffrey Keating wrote:
> Oops!  Forgot to attach the actual patches.  Fixed below.
> 
> 
> OK, so I have not one, but two patches!
> 
> The first one is less interesting.  It uses the language's name for the 
> function, unless it's a C++ function, in which case it uses the 
> (mangled) assembler name.  It'll give a stab like
> 
>         .stabs  "__ZN3bar3fooEv:F(0,1)",36,0,2,__ZN3bar3fooEv
> or
>         .stabs  "foo:F(0,1)",36,0,2,foo.11

This would probably work, but I think it's less useful.

> The second one uses the 'printable name' for the function.  That is, 
> for C it's just the name, and for C++ it's the demangled version of its 
> name.  I am not at all sure it'll work, because it gives stabs like:
> 
>         .stabs  "int bar::foo():F(0,1)",36,0,2,__ZN3bar3fooEv
> 
> which I suspect can't be parsed.

This won't work.  You're right; it's unparseable.  Could you manage to
generate "bar::foo:F(0,1)" instead?  GDB should handle that correctly
as-is.

> Could someone help me test these?  It needs a machine that can use 
> stabs and on which the GDB testsuite doesn't give too many false 
> positives.

i386-linux can do this.  I'd offer to do it, but only if Michael's too
busy - his test setup is vastly more thorough than I could manage.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Fwd: Two possible function stabs patches

[Geoffrey Keating]

[-- Attachment #1: Type: text/plain, Size: 858 bytes --]

Oops!  Forgot to attach the actual patches.  Fixed below.


OK, so I have not one, but two patches!

The first one is less interesting.  It uses the language's name for the 
function, unless it's a C++ function, in which case it uses the 
(mangled) assembler name.  It'll give a stab like

         .stabs  "__ZN3bar3fooEv:F(0,1)",36,0,2,__ZN3bar3fooEv
or
         .stabs  "foo:F(0,1)",36,0,2,foo.11

The second one uses the 'printable name' for the function.  That is, 
for C it's just the name, and for C++ it's the demangled version of its 
name.  I am not at all sure it'll work, because it gives stabs like:

         .stabs  "int bar::foo():F(0,1)",36,0,2,__ZN3bar3fooEv

which I suspect can't be parsed.

Could someone help me test these?  It needs a machine that can use 
stabs and on which the GDB testsuite doesn't give too many false 
positives.


[-- Attachment #2: gcc-funstab-mangled.patch --]
[-- Type: application/octet-stream, Size: 2149 bytes --]

Index: dbxout.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/dbxout.c,v
retrieving revision 1.156
diff -u -p -u -p -r1.156 dbxout.c
--- dbxout.c	19 Jul 2003 14:47:02 -0000	1.156
+++ dbxout.c	30 Jul 2003 00:53:32 -0000
@@ -2184,27 +2184,36 @@ dbxout_symbol (tree decl, int local ATTR
 	  || GET_CODE (XEXP (DECL_RTL (decl), 0)) != SYMBOL_REF)
 	break;
       FORCE_TEXT;
+      
+      {
+	const char *gdb_name;
 
-      fprintf (asmfile, "%s\"%s:%c", ASM_STABS_OP,
-	       IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (decl)),
-	       TREE_PUBLIC (decl) ? 'F' : 'f');
-      result = 1;
+	/* GDB knows how to demangle C++ mangled names, so treat those
+	   as the "real" name of the function.  Otherwise the "real" name
+	   is the name that the language has for the function.  */
+	gdb_name = IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (decl));
+	if (gdb_name[0] != '_' || gdb_name[1] != 'Z')
+	  gdb_name = IDENTIFIER_POINTER (DECL_NAME (decl));
 
-      current_sym_code = N_FUN;
-      current_sym_addr = XEXP (DECL_RTL (decl), 0);
-
-      if (TREE_TYPE (type))
-	dbxout_type (TREE_TYPE (type), 0);
-      else
-	dbxout_type (void_type_node, 0);
-
-      /* For a nested function, when that function is compiled,
-	 mention the containing function name
-	 as well as (since dbx wants it) our own assembler-name.  */
-      if (context != 0)
-	fprintf (asmfile, ",%s,%s",
-		 IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (decl)),
-		 IDENTIFIER_POINTER (DECL_NAME (context)));
+	fprintf (asmfile, "%s\"%s:%c", ASM_STABS_OP, gdb_name,
+		 TREE_PUBLIC (decl) ? 'F' : 'f');
+	result = 1;
+	
+	current_sym_code = N_FUN;
+	current_sym_addr = XEXP (DECL_RTL (decl), 0);
+	
+	if (TREE_TYPE (type))
+	  dbxout_type (TREE_TYPE (type), 0);
+	else
+	  dbxout_type (void_type_node, 0);
+	
+	/* For a nested function, when that function is compiled,
+	   mention the containing function name
+	   as well as (since dbx wants it) our own name.  */
+	if (context != 0)
+	  fprintf (asmfile, ",%s,%s", gdb_name,
+		   IDENTIFIER_POINTER (DECL_NAME (context)));
+      }
 
       dbxout_finish_symbol (decl);
       break;

[-- Attachment #3: gcc-funstab-printable.patch --]
[-- Type: application/octet-stream, Size: 1923 bytes --]

Index: dbxout.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/dbxout.c,v
retrieving revision 1.156
diff -u -p -u -p -r1.156 dbxout.c
--- dbxout.c	19 Jul 2003 14:47:02 -0000	1.156
+++ dbxout.c	30 Jul 2003 00:58:19 -0000
@@ -2184,27 +2184,32 @@ dbxout_symbol (tree decl, int local ATTR
 	  || GET_CODE (XEXP (DECL_RTL (decl), 0)) != SYMBOL_REF)
 	break;
       FORCE_TEXT;
+      
+      {
+	const char *gdb_name;
 
-      fprintf (asmfile, "%s\"%s:%c", ASM_STABS_OP,
-	       IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (decl)),
-	       TREE_PUBLIC (decl) ? 'F' : 'f');
-      result = 1;
+	/* Use the demangled version of the name.  */
+	gdb_name = lang_hooks.decl_printable_name (decl, 2);
 
-      current_sym_code = N_FUN;
-      current_sym_addr = XEXP (DECL_RTL (decl), 0);
-
-      if (TREE_TYPE (type))
-	dbxout_type (TREE_TYPE (type), 0);
-      else
-	dbxout_type (void_type_node, 0);
-
-      /* For a nested function, when that function is compiled,
-	 mention the containing function name
-	 as well as (since dbx wants it) our own assembler-name.  */
-      if (context != 0)
-	fprintf (asmfile, ",%s,%s",
-		 IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (decl)),
-		 IDENTIFIER_POINTER (DECL_NAME (context)));
+	fprintf (asmfile, "%s\"%s:%c", ASM_STABS_OP, gdb_name,
+		 TREE_PUBLIC (decl) ? 'F' : 'f');
+	result = 1;
+	
+	current_sym_code = N_FUN;
+	current_sym_addr = XEXP (DECL_RTL (decl), 0);
+	
+	if (TREE_TYPE (type))
+	  dbxout_type (TREE_TYPE (type), 0);
+	else
+	  dbxout_type (void_type_node, 0);
+	
+	/* For a nested function, when that function is compiled,
+	   mention the containing function name
+	   as well as (since dbx wants it) our own name.  */
+	if (context != 0)
+	  fprintf (asmfile, ",%s,%s", IDENTIFIER_POINTER (DECL_NAME (decl)),
+		   IDENTIFIER_POINTER (DECL_NAME (context)));
+      }
 
       dbxout_finish_symbol (decl);
       break;

[-- Attachment #4: Type: text/plain, Size: 40 bytes --]



-- 
Geoff Keating <geoffk@apple.com>