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

[Michael Elizabeth Chastain]

Geoff K suggests:

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

  break foo

Hmmmm.  I'll bet that this would be the first code in the test
suite with nested functions.  It is a supported gcc feature,
so that would be good to test.  We'll probably generate a bunch
of new KFAILs with this.

I'll put this on my TODO list, but I have to postpone this until
after the gdb 6.0 release.  It's a question of tuits.

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

Two possible function stabs patches

[Geoffrey Keating]

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.

-- 
Geoff Keating <geoffk@apple.com>