From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17097 invoked by alias); 9 Sep 2003 20:03:02 -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 17077 invoked from network); 9 Sep 2003 20:03:00 -0000 Received: from unknown (HELO zenia.home) (12.223.225.216) by sources.redhat.com with SMTP; 9 Sep 2003 20:03:00 -0000 Received: by zenia.home (Postfix, from userid 5433) id F14A220508; Tue, 9 Sep 2003 15:01:20 -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> <3F5E1A4C.9080300@redhat.com> From: Jim Blandy Date: Tue, 09 Sep 2003 20:03:00 -0000 In-Reply-To: <3F5E1A4C.9080300@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/msg00172.txt.bz2 Andrew Cagney writes: > > 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. > > Ah. Suggest adding a fixme describing this real problem to the code, > and filing a bug report. Okay, will do. The code should also try sect_index_rodata too, before giving up.