From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1325 invoked by alias); 9 Sep 2003 17:47:05 -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 1237 invoked from network); 9 Sep 2003 17:47:04 -0000 Received: from unknown (HELO zenia.home) (12.223.225.216) by sources.redhat.com with SMTP; 9 Sep 2003 17:47:04 -0000 Received: by zenia.home (Postfix, from userid 5433) id 3E624204FF; Tue, 9 Sep 2003 12:45:34 -0500 (EST) To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: PATCH: read stabs from files with no .data section References: <3F5D4961.4010407@redhat.com> From: Jim Blandy Date: Tue, 09 Sep 2003 17:47:00 -0000 In-Reply-To: <3F5D4961.4010407@redhat.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-09/txt/msg00164.txt.bz2 Andrew Cagney writes: > > + /* If the objfile has no .data section, try using the .bss section. */ > > + data_sect_index = objfile->sect_index_data; > > + if (data_sect_index == -1) > > + data_sect_index = SECT_OFF_BSS (objfile); > > + gdb_assert (data_sect_index != -1); > > + > > So what happens if there is no .data and no .bss? We lose. Maybe this should fall through the .rodata, and then .text section offsets, but I think it's still papering over the real problem, which I don't know how to solve. I think the correct behavior is to use the offset of the section containing the variable. Many of the old references to ANOFFSET (objfile->section_offsets, SECT_OFF_DATA (objfile)) that this patch changes were wrong, for this reason. But to do the right thing, we'd need to look up the section by the variable's unrelocated address, as with find_pc_section. This would be needed for every top-level variable, static and global, in the speed-critical partial symtab construction pass. I'm not sure that kind of overhead would be welcome. I'm certainly open to suggestions.