* 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; 7+ 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] 7+ messages in thread
* Re: Fwd: Two possible function stabs patches
2003-07-30 1:07 Fwd: Two possible function stabs patches Geoffrey Keating
@ 2003-07-30 1:14 ` Daniel Jacobowitz
2003-07-30 14:18 ` Andrew Cagney
1 sibling, 0 replies; 7+ 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] 7+ messages in thread
* Re: Fwd: Two possible function stabs patches
2003-07-30 1:07 Fwd: Two possible function stabs patches Geoffrey Keating
2003-07-30 1:14 ` Daniel Jacobowitz
@ 2003-07-30 14:18 ` Andrew Cagney
2003-08-01 22:36 ` Geoffrey Keating
1 sibling, 1 reply; 7+ 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] 7+ messages in thread
* Re: Two possible function stabs patches
2003-07-30 14:18 ` Andrew Cagney
@ 2003-08-01 22:36 ` Geoffrey Keating
0 siblings, 0 replies; 7+ messages in thread
From: Geoffrey Keating @ 2003-08-01 22:36 UTC (permalink / raw)
To: Andrew Cagney
Cc: Michael Elizabeth Chastain, gcc-patches, gdb, Daniel Jacobowitz
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>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Two possible function stabs patches
@ 2003-07-30 22:29 Michael Elizabeth Chastain
0 siblings, 0 replies; 7+ messages in thread
From: Michael Elizabeth Chastain @ 2003-07-30 22:29 UTC (permalink / raw)
To: geoffk; +Cc: drow, gcc-patches, gdb
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Two possible function stabs patches
2003-07-30 5:47 Fwd: " Michael Elizabeth Chastain
@ 2003-07-30 21:43 ` Geoffrey Keating
0 siblings, 0 replies; 7+ messages in thread
From: Geoffrey Keating @ 2003-07-30 21:43 UTC (permalink / raw)
To: Michael Elizabeth Chastain; +Cc: drow, gcc-patches, gdb
[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!
^ permalink raw reply [flat|nested] 7+ messages in thread
* Two possible function stabs patches
@ 2003-07-30 1:05 Geoffrey Keating
0 siblings, 0 replies; 7+ messages in thread
From: Geoffrey Keating @ 2003-07-30 1:05 UTC (permalink / raw)
To: Michael Elizabeth Chastain, gcc-patches, gdb, # Daniel Jacobowitz
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>
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2003-08-01 22:36 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-07-30 1:07 Fwd: Two possible function stabs patches Geoffrey Keating
2003-07-30 1:14 ` Daniel Jacobowitz
2003-07-30 14:18 ` Andrew Cagney
2003-08-01 22:36 ` Geoffrey Keating
-- strict thread matches above, loose matches on Subject: below --
2003-07-30 22:29 Michael Elizabeth Chastain
2003-07-30 5:47 Fwd: " Michael Elizabeth Chastain
2003-07-30 21:43 ` Geoffrey Keating
2003-07-30 1:05 Geoffrey Keating
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).