From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19334 invoked by alias); 23 Sep 2004 15:45:39 -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 18969 invoked from network); 23 Sep 2004 15:45:28 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (142.179.108.108) by sourceware.org with SMTP; 23 Sep 2004 15:45:28 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id C854E47D95; Thu, 23 Sep 2004 08:45:27 -0700 (PDT) Date: Thu, 23 Sep 2004 15:45:00 -0000 From: Joel Brobecker To: Michael Veksler Cc: gdb@sources.redhat.com Subject: Re: GDB unusable on AIX and lucky to work on HP-UX (PR1170) Message-ID: <20040923154527.GD968@gnat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-SW-Source: 2004-09/txt/msg00201.txt.bz2 On Thu, Sep 23, 2004 at 12:23:37PM +0200, Michael Veksler wrote: > > This is a bug long overdue, and makes C++ debugging on AIX impossible. I'd like to know how the other GDB maintainers feel about this bug report. I don't think that we should use a reproducer that forces us to switch stabs lines like this. I'd much rather use a real testcase. That way, I feel more comfortable knowing that I am fixing a real bug, and we can then add the testscase to our testsuite once the bug is fixed. Opinions? Michael, would have some code that would demonstrate the problem without the fiddling? I just looked at the testsuite results on AIX, where I use GCC 3.2.3 configured with C,C++ and Ada, and I didn't see any such internal-error. BTW, here are the results for the entire gdb.cp testcases (all our C++ testcases): === gdb Summary === # of expected passes 1681 # of unexpected failures 50 # of expected failures 2 # of known failures 23 # of unresolved testcases 2 This is with sources from CVS as of yesterday. > 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). > > > > > -- Joel