Fwd: Two possible function stabs patches

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>

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

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: Two possible function stabs patches

[Geoffrey Keating]

On Wednesday, July 30, 2003, at 07:17  AM, Andrew Cagney wrote:

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

So far as I know, this is a bug that has been in GCC since 1992, and 
before that I don't know what the history is.  I looked at the stabs 
document in GDB; this patch makes GCC more compliant with it.

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

All my old/slow boxen get used for GCC regression testing...

-- 
Geoff Keating <geoffk@apple.com>

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

[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: 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