(See README.txt in the attachment for full info) 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.
Created attachment 4654 [details] Description of bug, analysis, reference to the patch which produced it, sample files
I assigned this to myself because I think I know that one of my recent patches broke this.
I agree with Mark, it looks like this was caused by the change which removed the call to pushdecl from record_builtin_type. Mark, do you have any ideas on how this should be fixed? Probably not just by re-adding the pushdecl.
No, we certainly do not want to add back pushdecl. Instead, the stabs backend should generate stabs for the builtin types automatically, either as needed or always, at the start of the translation unit. I haven't had a chance to look at how to do that yet, but if it's getting in the way for the GDB folks, I will bump this up on my internal priority list.
Subject: Re: g++ generates stabs for "char *" that gdb cannot read On Mon, Sep 15, 2003 at 12:13:18AM -0000, mmitchel at gcc dot gnu dot org wrote: >PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org. > >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12066 > >------- Additional Comments From mmitchel at gcc dot gnu dot org 2003-09-15 00:13 ------- >No, we certainly do not want to add back pushdecl. > >Instead, the stabs backend should generate stabs for the builtin types >automatically, either as needed or always, at the start of the translation unit. > >I haven't had a chance to look at how to do that yet, but if it's getting in the >way for the GDB folks, I will bump this up on my internal priority list. This is definitely impacting my ability to use the gcc trunk with cygwin. Code generation seems to be ok but I can't debug anything due to this problem.
Subject: Bug 12066 CVSROOT: /cvs/gcc Module name: gcc Changes by: mmitchel@gcc.gnu.org 2003-09-17 20:52:46 Modified files: gcc : ChangeLog dbxout.c langhooks-def.h langhooks.c langhooks.h gcc/cp : ChangeLog cp-lang.c cp-tree.h decl.c Log message: PR debug/12066 * dbxout.c (dbxout_init): Use a langhook to find builtin types. * langhooks-def.h (lhd_return_null_tree_v): New function. (LANG_HOOKS_BUILTIN_TYPE_DECLS): New macro. (LANG_HOOKS_DECLS): Add it to the intializer. * langhooks.c (lhd_return_null_tree_v): New function. * langhooks.h (lang_hooks_for_decls): Add builtin_type_decls. PR debug/12066 * cp-lang.c (LANG_HOOKS_BUILTIN_TYPE_DECLS): Define. * cp-tree.h (cxx_builtin_type_decls): Declare. * decl.c (builtin_type_decls): New variables. (cxx_builtin_type_decls): New function. (record_builtin_type): Add to builtin_type_decls. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.1079&r2=2.1080 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/dbxout.c.diff?cvsroot=gcc&r1=1.157&r2=1.158 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/langhooks-def.h.diff?cvsroot=gcc&r1=1.67&r2=1.68 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/langhooks.c.diff?cvsroot=gcc&r1=1.53&r2=1.54 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/langhooks.h.diff?cvsroot=gcc&r1=1.74&r2=1.75 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.3683&r2=1.3684 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-lang.c.diff?cvsroot=gcc&r1=1.66&r2=1.67 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gcc&r1=1.916&r2=1.917 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gcc&r1=1.1126&r2=1.1127
Fixed in GCC 3.4.
Subject: Re: g++ generates stabs for "char *" that gdb cannot read It works for me. It fixes my specific test case, and it fixes many bad results in the gdb test suite. Thanks! Michael C