From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27995 invoked by alias); 26 Aug 2003 10:12:36 -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 27987 invoked from network); 26 Aug 2003 10:12:35 -0000 Received: from unknown (HELO concert.shout.net) (204.253.184.25) by sources.redhat.com with SMTP; 26 Aug 2003 10:12:35 -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 h7QACZrY007571 for ; Tue, 26 Aug 2003 05:12:35 -0500 Received: from duracef.shout.net (localhost [127.0.0.1]) by duracef.shout.net (8.12.9/8.12.9) with ESMTP id h7QACZHK022762 for ; Tue, 26 Aug 2003 05:12:35 -0500 Received: (from mec@localhost) by duracef.shout.net (8.12.9/8.12.9/Submit) id h7QACZgo022761 for gdb@sources.redhat.com; Tue, 26 Aug 2003 06:12:35 -0400 Date: Tue, 26 Aug 2003 10:12:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200308261012.h7QACZgo022761@duracef.shout.net> To: gdb@sources.redhat.com Subject: New stabs with gcc HEAD X-SW-Source: 2003-08/txt/msg00287.txt.bz2 [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 = ( *(*)( *)) 0x80482f4 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