* Re: New stabs with gcc HEAD
@ 2003-08-26 13:56 Michael Elizabeth Chastain
0 siblings, 0 replies; 4+ messages in thread
From: Michael Elizabeth Chastain @ 2003-08-26 13:56 UTC (permalink / raw)
To: drow, gdb
Here, let me just blort out the README.txt from the bug report that
I'm going to file (if we agree that we think it's a gcc bug).
===
Problem with g++ stabs+ builtin types
Michael Elizabeth Chastain, <mec@shout.net>
2003-08-26
Synopsis
g++ generates stabs for "char *" that gdb cannot read.
The bad stabs are:
.stabs "__builtin_va_list:t(0,10)=*(0,11)=r(0,11);0;127;",128,0,0,0
.stabs "_Z17dm_type_char_starPc:F(0,13)=*(0,11)",36,0,2,_Z17dm_type_char_starPc
The previous good stabs were:
.stabs "char:t(0,2)=r(0,2);0;127;",128,0,0,0
.stabs "__builtin_va_list:t(0,20)=*(0,2)",128,0,0,0
.stabs "_Z17dm_type_char_starPc:F(0,24)=*(0,2)",36,0,2,_Z17dm_type_char_starPc
This happens because g++ no longer generates an explicit stabs
record for "char", so the "char" gets defined with no name
in the middle of its first use in __builtin_va_list.
Files
README.txt this file
null.8207.s g++ -gstabs+ -x c++ -S /dev/null
null.8208.s g++ -gstabs+ -x c++ -S /dev/null
z1.cc small test program
z1.8207.s g++ -gstabs+ -S z1.cc
z1.8208.s g++ -gstabs+ -S z1.cc
z1.patch.s g++ -gstabs+ -S z1.cc
The "8207" files are with gcc version 2003-08-20 07:00:00 UTC.
The "8208" files are with gcc version 2003-08-20 08:00:00 UTC.
The z1.patch.s file is after applying my patch to gcc (see below).
Environment
target=native, host=i686-pc-linux-gnu, osversion=red-hat-8.0
gdb=5.3, gcc=2003-08-20 08:00:00 UTC, binutils=2.14, glibc=2.2.93-5-rh
gformat=stabs+, glevel=2
How To Reproduce
It's important to do this on with i386 target because the definition
of __builtin_va_list is relevant.
It's important to use -gstabs+.
Compile and link z1.cc with g++ HEAD from 2003-08-20 08:00:00 UTC or later.
binutils and glibc version do not matter.
Run gdb 5.3 or later.
(gdb) print &'dm_type_char_star(char*)'
$1 = (<invalid type code 7> *(*)(
<invalid type code 7> *)) 0x80482f4 <dm_type_char_star(char*)>
History Search
This patch caused the change:
2003-08-19 Mark Mitchell <mark@codesourcery.com>
...
PR c++/11036
...
* decl.c ...
(record_builtin_type): Do not call pushdecl.
http://gcc.gnu.org/ml/gcc-patches/2003-08/msg001155.html
I don't know the reason for this change.
Analysis
gdb complains because it can't figure out the stabs for the
return type of dm_type_char_star and the parameter type of
dm_type_char_star.
The bad stabs are:
.stabs "__builtin_va_list:t(0,10)=*(0,11)=r(0,11);0;127;",128,0,0,0
.stabs "_Z17dm_type_char_starPc:F(0,13)=*(0,11)",36,0,2,_Z17dm_type_char_starPc
You can see the whole file in z1.8208.s.
The problem is that many of the stabs for primitive types have gone
away. Compare z1.8207.s with z1.8208.s. Even more clearly, compare
null.8207.s with null.8208.s (types defined for an empty file).
__builtin_va_list needs "char *", so the stab for __builtin_va_list
defines a "char" type internally with no name. Then my function
dm_type_char_star ends up using the internal no-name type. The
no-name type confuses gdb.
For reference, __builtin_va_list on the i386 is built here:
/* config/i386/i386.c */
tree
ix86_build_va_list (void)
{
...
if (!TARGET_64BIT)
return build_pointer_type (char_type_node);
}
If you look at c_common_nodes_and_builtins, it uses two different
mechanisms to define types. Some types are defined with
record_builtin_type, and some of the types are defined with
(*lang_hooks.decls.pushdecl (build_decl (...))). Only the types
defined with pushdecl wind up in the stabs output.
How To Fix
I tried this and it worked for me:
--- /berman/fsf/_today_/source/gcc/HEAD/gcc/gcc/c-common.c 2003-08-20 18:36:08.000000000 -0400
+++ c-common.c 2003-08-26 04:52:29.000000000 -0400
@@ -3019,8 +3019,12 @@
tree va_list_arg_type_node;
/* Define `int' and `char' first so that dbx will output them first. */
- record_builtin_type (RID_INT, NULL, integer_type_node);
- record_builtin_type (RID_CHAR, "char", char_type_node);
+ (*lang_hooks.decls.pushdecl) (build_decl (TYPE_DECL,
+ get_identifier ("int"),
+ integer_type_node));
+ (*lang_hooks.decls.pushdecl) (build_decl (TYPE_DECL,
+ get_identifier ("char"),
+ char_type_node));
/* `signed' is the same as `int'. FIXME: the declarations of "signed",
"unsigned long", "long long unsigned" and "unsigned short" were in C++
This makes 'int' and 'char' always appear as explicit
distinct types in the debug output. z1.patch.s is gcc output
with this patch applied.
I don't even know the difference between 'record_builtin_type'
and 'pushdecl build_decl' so I expect that this patch is bogus.
But that's the general idea. 'char' needs to be explicit so
that __builtin_va_list does not define it implicitly. There are
probably quiet dependencies on explicit 'int' type as well.
Alternatively, one could change something else to process the
dependency of __builtin_va_list on 'char' so that an explicit
'char' type gets emitted. Anything that gets the 'char' type
emitted is fine.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: New stabs with gcc HEAD
@ 2003-08-26 15:24 Michael Elizabeth Chastain
0 siblings, 0 replies; 4+ messages in thread
From: Michael Elizabeth Chastain @ 2003-08-26 15:24 UTC (permalink / raw)
To: drow, gdb
Okay, I filed a gcc PR.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12066
This bumped up the non-PASS count for gdb 5.3 from 350 to 427.
Michael C
^ permalink raw reply [flat|nested] 4+ messages in thread
* New stabs with gcc HEAD
@ 2003-08-26 10:12 Michael Elizabeth Chastain
2003-08-26 13:44 ` Daniel Jacobowitz
0 siblings, 1 reply; 4+ messages in thread
From: Michael Elizabeth Chastain @ 2003-08-26 10:12 UTC (permalink / raw)
To: gdb
[Argh! I sent this to gcc@sources.redhat.com because I was thinking of gcc.
But I really want to talk about the issue with gdb people first!]
gcc HEAD changed its stabs and gdb is choking on the new stabs.
This happens with C++ and type "char *".
The test case is pretty simple:
char * dm_type_char_star (char *p)
{
return p;
}
int main ()
{
return 0;
}
Compile this with "g++ -gstabs+" with an i386 target.
(It's important to use an i386 because the bug depends on
target-specific definition of __builtin_va_list).
The old good stabs look like this:
.stabs "char:t(0,2)=r(0,2);0;127;",128,0,0,0
.stabs "__builtin_va_list:t(0,20)=*(0,2)",128,0,0,0
.stabs "_Z17dm_type_char_starPc:F(0,24)=*(0,2)",36,0,2,_Z17dm_type_char_starPc
There is a stab for "char" type. Then the types that use "char *"
refer back to (0,2).
The new bad stabs look like this:
.stabs "__builtin_va_list:t(0,10)=*(0,11)=r(0,11);0;127;",128,0,0,0
.stabs "_Z17dm_type_char_starPc:F(0,13)=*(0,11)",36,0,2,_Z17dm_type_char_starPc
There is no more stab for the builtin type "char". So
__builtin_va_list defines its own integral type as
(0,11) with no name, and then dm_type_char_star refers to it.
The lack of a name means gdb isn't going to print "char".
In fact, gdb 5.3 gets unhappy:
(gdb) print &'dm_type_char_star(char*)'
$1 = (<invalid type code 7> *(*)(
<invalid type code 7> *)) 0x80482f4 <dm_type_char_star(char*)>
gdb HEAD behaves the same way.
Over in gcc land, I found the critical patch, so it ought to
be easy for gcc to revert their behavior if we ask them to.
(In fact I even patched my own compiler but the patch is probably
bogus).
So my question is: should we enhance gdb to handle these stabs?
It would be painful, because there is no type name, so we would
have to infer from the "0;127" range that this is a "char".
Or should we push back on gcc to emit an explicit stab for
the "char" type?
Michael C
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: New stabs with gcc HEAD
2003-08-26 10:12 Michael Elizabeth Chastain
@ 2003-08-26 13:44 ` Daniel Jacobowitz
0 siblings, 0 replies; 4+ messages in thread
From: Daniel Jacobowitz @ 2003-08-26 13:44 UTC (permalink / raw)
To: gdb
On Tue, Aug 26, 2003 at 06:12:35AM -0400, Michael Elizabeth Chastain wrote:
> [Argh! I sent this to gcc@sources.redhat.com because I was thinking of gcc.
> But I really want to talk about the issue with gdb people first!]
>
> gcc HEAD changed its stabs and gdb is choking on the new stabs.
> This happens with C++ and type "char *".
>
> The test case is pretty simple:
>
> char * dm_type_char_star (char *p)
> {
> return p;
> }
>
> int main ()
> {
> return 0;
> }
>
> Compile this with "g++ -gstabs+" with an i386 target.
> (It's important to use an i386 because the bug depends on
> target-specific definition of __builtin_va_list).
>
> The old good stabs look like this:
>
> .stabs "char:t(0,2)=r(0,2);0;127;",128,0,0,0
> .stabs "__builtin_va_list:t(0,20)=*(0,2)",128,0,0,0
> .stabs "_Z17dm_type_char_starPc:F(0,24)=*(0,2)",36,0,2,_Z17dm_type_char_starPc
>
> There is a stab for "char" type. Then the types that use "char *"
> refer back to (0,2).
>
> The new bad stabs look like this:
>
> .stabs "__builtin_va_list:t(0,10)=*(0,11)=r(0,11);0;127;",128,0,0,0
> .stabs "_Z17dm_type_char_starPc:F(0,13)=*(0,11)",36,0,2,_Z17dm_type_char_starPc
>
> There is no more stab for the builtin type "char". So
> __builtin_va_list defines its own integral type as
> (0,11) with no name, and then dm_type_char_star refers to it.
>
> The lack of a name means gdb isn't going to print "char".
> In fact, gdb 5.3 gets unhappy:
>
> (gdb) print &'dm_type_char_star(char*)'
> $1 = (<invalid type code 7> *(*)(
> <invalid type code 7> *)) 0x80482f4 <dm_type_char_star(char*)>
>
> gdb HEAD behaves the same way.
>
> Over in gcc land, I found the critical patch, so it ought to
> be easy for gcc to revert their behavior if we ask them to.
> (In fact I even patched my own compiler but the patch is probably
> bogus).
>
> So my question is: should we enhance gdb to handle these stabs?
> It would be painful, because there is no type name, so we would
> have to infer from the "0;127" range that this is a "char".
> Or should we push back on gcc to emit an explicit stab for
> the "char" type?
I'd say GCC was broken. What patch broke it?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2003-08-26 15:24 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-08-26 13:56 New stabs with gcc HEAD Michael Elizabeth Chastain
-- strict thread matches above, loose matches on Subject: below --
2003-08-26 15:24 Michael Elizabeth Chastain
2003-08-26 10:12 Michael Elizabeth Chastain
2003-08-26 13:44 ` Daniel Jacobowitz
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).