From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12039 invoked by alias); 13 May 2002 03:16:59 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 12032 invoked from network); 13 May 2002 03:16:58 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 13 May 2002 03:16:58 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 1776KZ-0006wI-00; Sun, 12 May 2002 23:16:59 -0400 Date: Sun, 12 May 2002 20:16:00 -0000 From: Daniel Jacobowitz To: Michael Elizabeth Chastain Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] Fix gdb/277 by separating types Message-ID: <20020513031659.GA26356@nevyn.them.org> Mail-Followup-To: Michael Elizabeth Chastain , gdb-patches@sources.redhat.com References: <200205130310.g4D3A4R20206@duracef.shout.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200205130310.g4D3A4R20206@duracef.shout.net> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-05/txt/msg00439.txt.bz2 On Sun, May 12, 2002 at 10:10:04PM -0500, Michael Elizabeth Chastain wrote: > I do build an object directory from scratch (just to avoid these > kinds of problems). > > BTW I am using gcc 2.95.3, I don't know where you got 2.95.2 from. > > I bet the difference in our machines is somewhere in libc. > I am using stock red hat linux 7.2 glibc, glibc 2.2.4-13. Are you really? That's interesting. Debian does not include debug information in the system glibc, I'm quite surprised that Red Hat does. > It's reproducing on my machine. Here's a shorter recipe: > > ./gdb gdb.base/break > (gdb) break main > (gdb) run > (gdb) maint print symbols symbols_output > > Have a look at the end of symbols_output in the tarball. > Mine is reproducibly crapping out in file 'init.c' here: > > typedef void (*__gconv_end_fct)(); > typedef int (*__gconv_fct)(); > struct __gconv_info { > size_t __nsteps; > struct __gconv_step *__steps; > struct __gconv_step_data __data[0]; > }; > > typedef int (*__gconv_init_fct)(); > struct __gconv_step { > > When I do maint-print-symbols with gdb 5.2, it runs fine, > and gives me this output for __gconv_step: > > typedef int (*__gconv_init_fct)(struct __gconv_step *); > struct __gconv_step { > struct __gconv_loaded_object *__shlib_handle; > const char *__modname; > int __counter; > char *__from_name; > char *__to_name; > int (*__fct)(struct __gconv_step *, struct __gconv_step_data *, const unsigned char **, const unsigned char *, unsigned char **, size_t *, int, int); > int (*__init_fct)(struct __gconv_step *); > void (*__end_fct)(struct __gconv_step *); > int __min_needed_from; > int __max_needed_from; > int __min_needed_to; > int __max_needed_to; > int __stateful; > void *__data; > }; The const in __fct is probably what's killing it... > In the stack trace, I'm seeing it crap out on c_print_type of > __shlib_handle. __gconv_loaded_object is a forward reference, > but it is not defined in this symtab: it is defined in a different > symtab. Sure enough, I can reproduce the failures if I use a libc with debug symbols. I'll investigate; patch tabled for the moment. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer