From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25424 invoked by alias); 5 Apr 2004 19:09:51 -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 25329 invoked from network); 5 Apr 2004 19:09:42 -0000 Received: from unknown (HELO mclean.mail.mindspring.net) (207.69.200.57) by sources.redhat.com with SMTP; 5 Apr 2004 19:09:42 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by mclean.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1BAZTY-0008Cx-00; Mon, 05 Apr 2004 15:09:41 -0400 Received: by berman.michael-chastain.com (Postfix, from userid 502) id 23D084B104; Mon, 5 Apr 2004 15:09:42 -0400 (EDT) To: ezannoni@redhat.com, gdb@sources.redhat.com, jimb@redhat.com Subject: gcc HEAD, stabs+, TYPE_CODE_INT problem Message-Id: <20040405190942.23D084B104@berman.michael-chastain.com> Date: Mon, 05 Apr 2004 19:09:00 -0000 From: mec.gnu@mindspring.com (Michael Elizabeth Chastain) X-SW-Source: 2004-04/txt/msg00027.txt.bz2 My last test run got stabbed really badly by a new problem with gcc HEAD -gstabs+. There are about 700 new non-PASS results. The symptoms are: look at a global variable of type "char *". # gcc 3.3.3 (gdb) ptype s type = char * # gcc HEAD 2004-03-30 (gdb) ptype s type = * "invalid type code 7" is TYPE_CODE_INT. With gcc 3.3.3, the stabs look like this: # gcc 3.3.3 .stabs "char:t(0,2)=r(0,2);0;127;",128,0,0,0 .stabs "__caddr_t:t(7,35)=(7,36)=*(0,2)",128,0,82,0 .stabs "s:G(7,36)",32,0,7,0 With gcc HEAD, the stabs look like this: # gcc HEAD .stabs "__caddr_t:t(3,44)=(3,45)=*(3,46)=r(3,46);0;127;",128,0,82,0 .stabs "s:G(3,45)",32,0,7,0 That is, gcc 3.3.3 emits a separate line for each primitive type such as "char". gcc HEAD emits the definition of "char" as a nested definition inside the first type that uses char, such as pointer-to-char. The big question is: is this legal stabs? After reading stabs.texinfo, I'm inclined to think that it is. If it's legal stabs, then someone has to enhance the stab reader. I haven't started debugging gdb yet but I suspect that bit of code is getting confused by the new-style nested definition. There's a bit of code in read_range_type to recognize the special case of "char" as 0 to 127, and gdb is behaving like that special-case isn't getting recognized. If this code is *not* legal stabs, then I can make a small test case and then file a gcc PR. I already isolated the gcc patch which causes this. It's a big C-declaration rewrite. Michael C