From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20533 invoked by alias); 23 Sep 2004 10:21:17 -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 20422 invoked from network); 23 Sep 2004 10:21:11 -0000 Received: from unknown (HELO mtagate2.de.ibm.com) (195.212.29.151) by sourceware.org with SMTP; 23 Sep 2004 10:21:11 -0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i8NALAFW125318 for ; Thu, 23 Sep 2004 10:21: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 i8NAL9U3209122 for ; Thu, 23 Sep 2004 12:21:09 +0200 In-Reply-To: Subject: GDB unusable on AIX and lucky to work on HP-UX (PR1170) To: gdb@sources.redhat.com Message-ID: From: Michael Veksler Date: Thu, 23 Sep 2004 10:21:00 -0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-SW-Source: 2004-09/txt/msg00197.txt.bz2 This is a bug long overdue, and makes C++ debugging on AIX impossible. I could reproduce it for simple C code: /* compile with gcc -g -S */ int get_int1() { const int zero= 0; return zero; } int get_int2() { const int zero= 0; return zero; } int main() { return 0; } If you reorder get_int1 and get_int2 in the ASM file gdb will crash. (/bin/as is allowed to do so, and it does reorder in big test cases). This reordering works fine when compiled with gcc -gstabs on Linux. It seems to be triggered by the combination of stabs and COFF. Since HP-UX seems to be COFF based I suspect that HP-UX is also affected. Can someone confirm this? I seek for advice on how to correctly fix for this. There are 3 ways: 1. Make gdb behave well when it reads debug info in a "wrong" order. Any advice on this is welcome. 2. Change gcc to emit =k-{n} (e.g. =k-1) for all instances of constant built-in type (instead of only once per type). This is the patch this PR mentions, but David Edelsohn objects because he thinks it is the wrong way to fix it. If =k-{n} is required to repeat by stabs format, then it means that the correct fix *is* in gcc and should resemble my patch. 3. Change gcc to avoid =k-{n} format altogether in these cases. I think that solution 1 is the correct one. I looked at xlC output and came to realize that xlC may trigger the same bug in gdb (if gdb understood xlC's C++). Michael Veksler/Haifa/IBM @IBMIL To Sent by: gdb@sources.redhat.com gdb-owner@sources cc .redhat.com Subject PR1170: wrong assumption on stab = 20/09/2004 13:34 crash 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).