From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25653 invoked by alias); 7 Nov 2002 19:41:48 -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 25633 invoked from network); 7 Nov 2002 19:41:45 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (142.179.108.108) by sources.redhat.com with SMTP; 7 Nov 2002 19:41:45 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 9401AD2CCC; Thu, 7 Nov 2002 11:44:34 -0800 (PST) Date: Thu, 07 Nov 2002 11:41:00 -0000 From: Joel Brobecker To: gdb-patches@sources.redhat.com Subject: Design problem with min sym relocation? Message-ID: <20021107194434.GY5164@gnat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-SW-Source: 2002-11/txt/msg00187.txt.bz2 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: 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