From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26022 invoked by alias); 15 Nov 2001 06:52:54 -0000 Mailing-List: contact gdb-patches-help@sourceware.cygnus.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 25869 invoked from network); 15 Nov 2001 06:52:42 -0000 Received: from unknown (HELO dublin.ACT-Europe.FR) (212.157.227.154) by sourceware.cygnus.com with SMTP; 15 Nov 2001 06:52:42 -0000 Received: from berlin.ACT-Europe.FR (berlin.act-europe.fr [212.157.227.169]) by dublin.ACT-Europe.FR (Postfix) with ESMTP id 5504422A071; Thu, 15 Nov 2001 07:52:43 +0100 (MET) Received: by berlin.ACT-Europe.FR (Postfix, from userid 507) id 7CF4B825; Thu, 15 Nov 2001 07:52:42 +0100 (CET) Date: Tue, 06 Nov 2001 07:40:00 -0000 From: Joel Brobecker To: Elena Zannoni Cc: gdb-patches@sources.redhat.com Subject: Re: [patch] Fix uninitialized section index internal error Message-ID: <20011115075241.A26308@act-europe.fr> References: <20010510234031.A17108@act-europe.fr> <15142.34631.889495.152234@kwikemart.cygnus.com> <20010615084043.E10731@act-europe.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010615084043.E10731@act-europe.fr>; from brobecker@act-europe.fr on Fri, Jun 15, 2001 at 08:40:43AM +0200 X-SW-Source: 2001-11/txt/msg00079.txt.bz2 Hi Elena, I finally had some time to look at the problem we encounter on Tru64 5.1... It's been a long sime since we last discussed this, so here is a pointer to the original message: http://sources.redhat.com/ml/gdb-patches/2001-05/msg00187.html I can actually reproduce the internal error with an empty program without needing to link in libmach.so... So, I modified mdebugread.c to separate the handling of symbols located in the BSS section and the symbols located in the SBSS section, just as you suggested. I thought that would make the internal-error disappear, but they did not :-(. After investigating a bit more, I found that the linker creates a certain number of special symbols, such as _ebss, or _fdata for instance. The Compacq documentation says that all these symbols are labels. These labels are used as adresses to mark the begining or the end of a particular part of the an object file. For instance, _ebss marks the end of the .bss section. The "trick" that confuses gdb in our example is that the symbol table in the executable contains an entry for the "_ebss" symbol, which storage class is scBss (and I verified this with the native odump utility). However, the .bss section does not exist! This is not the only symbol that is causing trouble, others are in a similar case. I noticed that the problem arrises with the .data section when we try to load the symbols of /usr/shlib/libm.so, for instance. So it appears that having a symbol referencing a section does not necessarily means that this section actually exists, not for Label symbols. I'm not sure how to fix this in GDB. I can see several options. The solution that seems the most reasonable to me is to check whether the section exists before making the address of the Label symbol relative to the section start address. Otherwise, if the symbol refers to a non-existent section, then keep the address as-is and set the storage class to "unknown". This seems a bit "hacky" to me, because we are not being very consistant on how we consider the address of the label (relative or not relative, that is the question). Another approach, which has the merit of simplifying the code (maybe a bit too much) is to say: all label addresses are absolute, and we don't really care which section they are refering to. So the whole stLabel case code-section collapses to the following line: ms_type = mst_unknown; /* value is already set to ext_in->asym.value */ I find this approach quite attractive, but I am afraid that it might be a bit too simplistic to be correct... Let me know what you think, Thanks. -- Joel