From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30251 invoked by alias); 19 Jan 2002 19:26:10 -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 30142 invoked from network); 19 Jan 2002 19:26:07 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 19 Jan 2002 19:26:07 -0000 Received: from telocity.telocity.com (taarna.sfbay.redhat.com [205.180.230.102]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with SMTP id LAA02929; Sat, 19 Jan 2002 11:25:58 -0800 (PST) Message-ID: <3C49C737.6C71@redhat.com> Date: Sat, 19 Jan 2002 11:26:00 -0000 From: Michael Snyder X-Mailer: Mozilla 3.04 (Win95; I) MIME-Version: 1.0 To: Daniel Jacobowitz CC: gdb-patches@sources.redhat.com Subject: Re: [RFA] Fix for searching for data symbols References: <20020119123318.A1378@nevyn.them.org> <3C49B256.3B38@redhat.com> <20020119130506.A2201@nevyn.them.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-01/txt/msg00539.txt.bz2 Daniel Jacobowitz wrote: > > On Sat, Jan 19, 2002 at 09:52:22AM -0800, Michael Snyder wrote: > > Daniel Jacobowitz wrote: > > > > > > This patch fixes the problem I described in: > > > http://sources.redhat.com/ml/gdb/2002-01/msg00223.html > > > > > > Basically, since we use the bounds of the text segment to search for symbols > > > in find_pc_*, don't let them return a bogus answer for a symbol we know is > > > off in data land. > > > > > > OK to commit, or does anyone prefer a different approach to this? > > > > Is there any chance that a data symbol that we don't want > > would shadow a text symbol that we do want? Eg. maybe in > > one module we have > > static int foo; > > and in another we have > > extern int foo(void); > > Maybe they are even in separate objfiles (shared libs). > > Maybe lookup_minimal_symbol will find the wrong one first, > > and your change will terminate the search before we would > > have found the right one? > > > > Just speculating... > > Well, we aren't using lookup_minimal_symbol; we're using > lookup_minimal_symbol_by_pc_section. I don't think it's possible for > it to get the wrong one, since it's by address instead of by name. OK, good, that answers that concern. Thanks.