From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23433 invoked by alias); 9 Sep 2003 18:22:09 -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 23423 invoked from network); 9 Sep 2003 18:22:06 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 9 Sep 2003 18:22:06 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 149112B7F; Tue, 9 Sep 2003 14:22:05 -0400 (EDT) Message-ID: <3F5E1A4C.9080300@redhat.com> Date: Tue, 09 Sep 2003 18:22:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Blandy Cc: gdb-patches@sources.redhat.com Subject: Re: PATCH: read stabs from files with no .data section References: <3F5D4961.4010407@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-09/txt/msg00166.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. Ah. Suggest adding a fixme describing this real problem to the code, and filing a bug report. enjoy, Andrew