From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4692 invoked by alias); 26 Aug 2003 13:56:48 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 4684 invoked from network); 26 Aug 2003 13:56:46 -0000 Received: from unknown (HELO concert.shout.net) (204.253.184.25) by sources.redhat.com with SMTP; 26 Aug 2003 13:56:46 -0000 Received: from duracef.shout.net (duracef.shout.net [204.253.184.12]) by concert.shout.net (8.12.9/8.12.9) with ESMTP id h7QDuhrY001682; Tue, 26 Aug 2003 08:56:43 -0500 Received: from duracef.shout.net (localhost [127.0.0.1]) by duracef.shout.net (8.12.9/8.12.9) with ESMTP id h7QDuhHK025338; Tue, 26 Aug 2003 08:56:43 -0500 Received: (from mec@localhost) by duracef.shout.net (8.12.9/8.12.9/Submit) id h7QDuhDm025337; Tue, 26 Aug 2003 09:56:43 -0400 Date: Tue, 26 Aug 2003 13:56:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200308261356.h7QDuhDm025337@duracef.shout.net> To: drow@mvista.com, gdb@sources.redhat.com Subject: Re: New stabs with gcc HEAD X-SW-Source: 2003-08/txt/msg00289.txt.bz2 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, 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 = ( *(*)( *)) 0x80482f4 History Search This patch caused the change: 2003-08-19 Mark Mitchell ... 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.