* Re: Fwd: Two possible function stabs patches
@ 2003-07-30 15:20 Michael Elizabeth Chastain
0 siblings, 0 replies; 6+ messages in thread
From: Michael Elizabeth Chastain @ 2003-07-30 15:20 UTC (permalink / raw)
To: drow, gcc-patches, gdb, geoffk
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Fwd: Two possible function stabs patches
2003-07-30 1:07 Geoffrey Keating
2003-07-30 1:14 ` Daniel Jacobowitz
@ 2003-07-30 14:18 ` Andrew Cagney
1 sibling, 0 replies; 6+ messages in thread
From: Andrew Cagney @ 2003-07-30 14:18 UTC (permalink / raw)
To: Geoffrey Keating
Cc: Michael Elizabeth Chastain, gcc-patches, gdb, Daniel Jacobowitz
> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Fwd: Two possible function stabs patches
@ 2003-07-30 5:47 Michael Elizabeth Chastain
0 siblings, 0 replies; 6+ messages in thread
From: Michael Elizabeth Chastain @ 2003-07-30 5:47 UTC (permalink / raw)
To: drow, gcc-patches, gdb, geoffk
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Fwd: Two possible function stabs patches
@ 2003-07-30 1:39 Michael Elizabeth Chastain
0 siblings, 0 replies; 6+ messages in thread
From: Michael Elizabeth Chastain @ 2003-07-30 1:39 UTC (permalink / raw)
To: drow, gcc-patches, gdb, geoffk
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Fwd: Two possible function stabs patches
2003-07-30 1:07 Geoffrey Keating
@ 2003-07-30 1:14 ` Daniel Jacobowitz
2003-07-30 14:18 ` Andrew Cagney
1 sibling, 0 replies; 6+ messages in thread
From: Daniel Jacobowitz @ 2003-07-30 1:14 UTC (permalink / raw)
To: Geoffrey Keating; +Cc: Michael Elizabeth Chastain, gcc-patches, gdb
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Fwd: Two possible function stabs patches
@ 2003-07-30 1:07 Geoffrey Keating
2003-07-30 1:14 ` Daniel Jacobowitz
2003-07-30 14:18 ` Andrew Cagney
0 siblings, 2 replies; 6+ messages in thread
From: Geoffrey Keating @ 2003-07-30 1:07 UTC (permalink / raw)
To: Michael Elizabeth Chastain, gcc-patches, gdb, Daniel Jacobowitz
[-- 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>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-07-30 15:20 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-07-30 15:20 Fwd: Two possible function stabs patches Michael Elizabeth Chastain
-- strict thread matches above, loose matches on Subject: below --
2003-07-30 5:47 Michael Elizabeth Chastain
2003-07-30 1:39 Michael Elizabeth Chastain
2003-07-30 1:07 Geoffrey Keating
2003-07-30 1:14 ` Daniel Jacobowitz
2003-07-30 14:18 ` Andrew Cagney
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).