This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: New stabs with gcc HEAD
- From: Michael Elizabeth Chastain <mec at shout dot net>
- To: drow at mvista dot com, gdb at sources dot redhat dot com
- Date: Tue, 26 Aug 2003 09:56:43 -0400
- Subject: Re: New stabs with gcc HEAD
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.