From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10472 invoked by alias); 20 Sep 2004 10:32:13 -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 10465 invoked from network); 20 Sep 2004 10:32:11 -0000 Received: from unknown (HELO mtagate4.de.ibm.com) (195.212.29.153) by sourceware.org with SMTP; 20 Sep 2004 10:32:11 -0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i8KAWALi148668 for ; Mon, 20 Sep 2004 10:32:10 GMT Received: from d12ml102.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8KAWAK2195328 for ; Mon, 20 Sep 2004 12:32:10 +0200 Subject: PR1170: wrong assumption on stab = crash To: gdb@sources.redhat.com Message-ID: From: Michael Veksler Date: Mon, 20 Sep 2004 10:32:00 -0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-SW-Source: 2004-09/txt/msg00161.txt.bz2 http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=1170 1. First I'll describe how to reproduce (will probably crash on other stab+coff systems) 2. Later I'll explain why this happens. 3. Then I'll ask how this should be fixed. ---- How to reproduce ---- On AIX, (maybe on other systems) the folding will crash gdb (5.3, and as I remember, 6.0 and later): // g++ -g struct X { static const int firstInt = 0; }; struct Y { static const int secondInt = 0; }; int main() { } Move the stabstring about 'firstInt' till after the stabstring about 'main' (something that /bin/as and /bin/ld are allowed to do). Now, in gdb do either: 'ptype Y', or 'break main' At this point you should get: gdbtypes.c:515: gdb-internal-error: make_cv_type: Assertion `TYPE_OBJFILE (*typeptr) == TYPE_OBJFILE (type) || TYPE_STUB (*typeptr)' failed. An internal GDB error was detected. This ....... ---- What causes the crash ---- 'firstInt' is assigned a new type-id (13) which is a typedef of the build in 'int': X:Tt12=s1firstInt:/213=k-1:........ ^^ ^^^ type-id built-in type (1 == int). 'secondInt' reuses the same type-id: Y:Tt21=s1secondInt:/213:.... ^^ type-id Now /bin/as or /bin/ld move firstInt stabstring much after secondInt. GDB reads the symbols in order: 1. secondInt:/213, gdb puts a new type-id = 13 in a symbol table. This is an incomplete type. 2. firstInt:/213=k-1, oops this is not an incomplete type but a const built-in type. An assertion in make_cv_type fails. A comment preceding this assertion reads: /* Objfile is per-core-type. This const-qualified type had best belong to the same objfile as the type it is qualifying, unless we are overwriting a stub type, in which case the safest thing to do is to copy the core type into the new objfile. */ ---- How to fix ---- Removing the assertion does not resolve the core issue. Is it possible to update change type information when GDB learns more about the type? It must be the case for: struct A ; struct A { /* some stuff */ }; Why is it not the case for 'static const int firstInt=0' ? Is there something deep in the infrastructure that prevents this? Is it because of late addition of c-v (const/volatile)? Is it a bug in gcc - which should emit "13=k-1" every time instead of plain "13" (it should not loose the const qualifier).