From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32005 invoked by alias); 14 Apr 2002 22:39:03 -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 31994 invoked from network); 14 Apr 2002 22:39:00 -0000 Received: from unknown (HELO cygnus.com) (205.180.83.203) by sources.redhat.com with SMTP; 14 Apr 2002 22:39:00 -0000 Received: from localhost.redhat.com (remus.sfbay.redhat.com [172.16.27.252]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id PAA01288 for ; Sun, 14 Apr 2002 15:38:59 -0700 (PDT) Received: by localhost.redhat.com (Postfix, from userid 469) id 7240411431; Sun, 14 Apr 2002 18:38:39 -0400 (EDT) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15546.1263.304306.933281@localhost.redhat.com> Date: Sun, 14 Apr 2002 15:39:00 -0000 To: Joel Brobecker Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC] Uninitialized section index internal error on Tru64 5.1 In-Reply-To: <20020412121941.E16134@act-europe.fr> References: <20020412121941.E16134@act-europe.fr> X-SW-Source: 2002-04/txt/msg00511.txt.bz2 Joel Brobecker writes: > This follows up on a discussion started over a year ago... Lack of time > prevented me from persuing this issue. Hopefully we can make progress > quickly. The last message on this topic was sent by me, and contains > a full description of what I believe is the source of the problem: > > http://sources.redhat.com/ml/gdb-patches/2001-11/msg00296.html > > The following patch fixes many regressions in the testsuite: > Summary 1 2 > FAIL 1644 792 > PASS 4388 6990 > XFAIL 59 149 > XPASS 1 3 > > I compiled on Tru64 5.1A, using GCC. > > This patch is not meant to be integrated as is, this is more a first > rough fix presented so that we can discuss more precisely which > direction to take in order to complete the work. > I don't mind this patch as is actually. > In particular, should the "if section-is-uninitialized then discard" > bits be always there regardless of the target? Or should we put in place > some configure test in order to execute this test only on targets were > this is needed (alpha-osf is the only one that I know of). > Yeah, I see your point. It seems like the real problem is that a storage class is assigned w/o a corresponding section being there. Does the section ever exist, does it get optimized out at some point? Your comments explain pretty well what's going on, so I am inclined to leave the "continue's" in. > There is also the get_section_index function that I quickly threw in. I > suppose it should be defined in a .h file, and implemented somewhere > else than in mdebugread.c. > I would suggest symfile.c and symfile.h. Elena > Cheers, > -- > Joel