From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2977 invoked by alias); 8 Nov 2002 22:58:51 -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 2970 invoked from network); 8 Nov 2002 22:58:50 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 8 Nov 2002 22:58:50 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id gA8Ma1w17397 for ; Fri, 8 Nov 2002 17:36:01 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id gA8Mwof17005 for ; Fri, 8 Nov 2002 17:58:50 -0500 Received: from localhost.redhat.com (romulus-int.sfbay.redhat.com [172.16.27.46]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id gA8Mwns10697 for ; Fri, 8 Nov 2002 17:58:49 -0500 Received: by localhost.redhat.com (Postfix, from userid 469) id E1E59FF79; Fri, 8 Nov 2002 17:54:40 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15820.16559.583264.665088@localhost.redhat.com> Date: Fri, 08 Nov 2002 14:58:00 -0000 To: Joel Brobecker Cc: gdb-patches@sources.redhat.com Subject: Re: Design problem with min sym relocation? In-Reply-To: <20021107194434.GY5164@gnat.com> References: <20021107194434.GY5164@gnat.com> X-SW-Source: 2002-11/txt/msg00257.txt.bz2 Joel Brobecker writes: > This is something I found out a while ago, and forgot to mention it > here. It happens on alpha-osf, but this is probably a general issue. > > The current version of GDB used at ACT is based on GDB 5.1.1. We get > an internal error when doing the following on Tru64 4.0f: > > (gdb) file /usr/shlib/libm.so > Reading symbols from /usr/shlib/libm.so...mdebugread.c:2445: > gdb-internal-error: sect_index_data not initialized > > An internal GDB error was detected. This may make further > debugging unreliable. Quit this debugging session? (y or n) > > This is caused by a symbol called "signgam" which is located in the > .sdata section. The problem is that GDB seems to be insisting on > coalescing all .*data sections in the same lot, if I understand > parse_partial_symbols in mdebugread.c correctly: > > else if (SC_IS_DATA (ext_in->asym.sc)) > { > ms_type = mst_data; > svalue += ANOFFSET (objfile->section_offsets, > SECT_OFF_DATA (objfile)); > } > > (SC_IS_DATA matches data, sdata, pdata, etc sections) > > I think this code snipet shows 2 problems: > 1. We relocated based on the .data section. In our case, 2e should > relocate relative to the .sdata section. That would be quite > easy to fix. > 2. ms_type is set to mst_data. This seems to be later used by > prim_record_minimal_symbol vis: > > case mst_data: > case mst_file_data: > section = SECT_OFF_DATA (objfile); > > This would be a bit more difficult to fix without adding new > enum values for each data section kind. > > I tried reproducing this problem on Tru64 5.1a, but this time with no > luck. I checked this symbol, and it is still there, and still in the > .sdata section. But this time, the shared object has a .data section. > So my bet is that GDB computes temporarily gets away with the problem > this time, but computes an incorrect address for this symbol. > > I tried with a more recent version of the code, and the internal error > is gone. I don't know if I should rejoyce or not, as I still see the > piece of code that I pasted above. > > This is all based on code inspection (cruelly lacking the time to look > more into the problem), but I think there is still a latent problem > where we compute incorrect addresses for certain symbols located in non > mainstream sections (like in the .sdata instead of the .data section). > > I would greatly appreciate your thoughs on the issue. My view is that > we should get rid of these SC_IS_* and SECT_OFF_* macros, add new > mst_* enums (one for each section kind), and add services that > compute the ms_type from the section kind, and compute the section > index of a given ms_type. This would give us something like: Yes. I remember looking at another similar problem in mdebugread.c for which the solution was to split SC_IS_BSS and add a new, more precise SC_IS_SBSS. [goes look....hey it was you! :)] http://sources.redhat.com/ml/gdb-patches/2001-06/msg00244.html Would a similar approach help in this case? Definitely the SECT_OFF should eventually go. I guess I can call that a pipe-dream. Elena > > ms_type = get_ms_type_from_storage_class (ext_in->asym.sc); > svalue += ANOFFSET (objfile->section_offsets, section_index (ms_type)); > > in mdebugread.c (should move the big ifs list out of parse_partial_symbols), > and then something like this in prim_record_minimal_symbol(): > > section = section_index (ms_type); > > At the time when I looked at this, I did not start this conversion > because I thought it might touch a large number of file, which I am always > reluctant to do before getting any feedback, especially when it touches > the current design. > -- > Joel