From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22010 invoked by alias); 14 Aug 2003 13:17: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 22003 invoked from network); 14 Aug 2003 13:17:38 -0000 Received: from unknown (HELO maxipes.logix.cz) (81.0.234.97) by sources.redhat.com with SMTP; 14 Aug 2003 13:17:38 -0000 Received: from suse.cz (styx.suse.cz [213.210.157.162]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "Michal Ludvig", Issuer "Personal Freemail RSA 2000.8.30" (verified OK)) by maxipes.logix.cz (Postfix) with ESMTP id CD082299D9; Thu, 14 Aug 2003 15:17:36 +0200 (CEST) Message-ID: <3F3B8C04.1010309@suse.cz> Date: Thu, 14 Aug 2003 13:17:00 -0000 From: Michal Ludvig Organization: SuSE CR, s.r.o. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.5b) Gecko/20030813 X-Accept-Language: cs, cz, en MIME-Version: 1.0 To: Elena Zannoni Cc: gdb , Daniel Jacobowitz Subject: Re: Dwarf2-related Internal error References: <3F0AD6F4.9060709@suse.cz> <3F3B6C99.6020908@suse.cz> <16187.34103.759484.814559@localhost.redhat.com> In-Reply-To: <16187.34103.759484.814559@localhost.redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-08/txt/msg00148.txt.bz2 Elena Zannoni told me that: > Michal Ludvig writes: > > Hi Daniel, Elena and others, > > this problem is still present in recent HEAD - could anyone who knows > > the internals of symbols handling and .debug_info please help me with > > fixing it, please? I tried to debug it myself but got quickly lost in > > all those symbols<->types<->other_types references and couldn't find > > where the problem originates. > > > > Also pointing out the right direction where to look for the bug would > > help me a lot :-) > > > > BTW I also filled a PR with a very nice number 1333 for this issue. > > > > Thanks in advance! > > > > Michal Ludvig > > I don't have much time to devote to this, but usually that kind of > error is generated by some infinite loop that gdb got itself into. Unlikely. The immediate problem is that the size of function's parameter 'xx' is too big: (top-gdb) f #0 read_var_value (var=0x8b35c0, frame=0x85ad98) at ../../gdb-head/gdb/findvar.c:397 397 struct type *type = SYMBOL_TYPE (var); (top-gdb) p *var->type $2 = {pointer_type = 0x0, reference_type = 0x0, chain = 0x89fc00, instance_flags = 0, length = 4294967292, main_type = 0x89fc28} (top-gdb) p (int)4294967292 $3 = -4 (top-gdb) Very likely it was ment to be -4 because something somewhere in the debug info was wrongly interpreted. From what is this length computed and where? Somewhere in dwarf2read.c? > Does the same happen for 386? Maybe comparing the two would help. Unfortunately i386 generates completely different code and debug info (it apparently doesn't use dwarf2 - maybe dwarf1? Sections .debug, .lines, ...) that couldn't be reasonably compared. I wasn't able to convince it to produce dwarf2 :-( Thanks for the reply anyway :-) Michal Ludvig -- * SuSE CR, s.r.o * mludvig@suse.cz * (+420) 296.545.373 * http://www.suse.cz