From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29304 invoked by alias); 27 Jan 2004 22:23:14 -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 29287 invoked from network); 27 Jan 2004 22:23:13 -0000 Received: from unknown (HELO localhost.redhat.com) (66.187.230.200) by sources.redhat.com with SMTP; 27 Jan 2004 22:23:13 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 115202B8F; Tue, 27 Jan 2004 17:19:46 -0500 (EST) Message-ID: <4016E401.2050001@gnu.org> Date: Tue, 27 Jan 2004 22:23:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 MIME-Version: 1.0 To: gdb-patches@sources.redhat.com Subject: [rfa/symtab] Move find_pc_section call to lookup_minimal_symbol_by_pc Content-Type: multipart/mixed; boundary="------------000906010601080300070401" X-SW-Source: 2004-01/txt/msg00706.txt.bz2 This is a multi-part message in MIME format. --------------000906010601080300070401 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-length: 897 Hello, Ref: RFA symtab: Fix for PR c++/1267 ("next" and shared libraries) http://sources.redhat.com/ml/gdb-patches/2003-07/msg00354.html The change unfortunatly broke IRIX 6.5's host compiler which is using mdebugread :-( That code was looking for a symbol in the absolute section "*ABS*" but the PR/1267 change was causing *ABS* symbols to be ignored (find_pc_section didn't return an absolute section). Since the underlying problem with PR/1267 was with the frame code needing a minimal symbol that was in the same section as the frame's PC, and that code [indirectly] calls lookup_minimal_symbol_by_pc, I moved the find_pc_section call to that function. Tested on i386 GNU/Linux (dwarf 2) with no regressions. Tested on PPC NetBSD (stabs) with no regressions. Tested on IRIX and all the warnings, and many failures, disappeared. See gdb/1519 for how to exercise the bug. ok? Andrew --------------000906010601080300070401 Content-Type: text/plain; name="diffs" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="diffs" Content-length: 3199 2004-01-27 Andrew Cagney * minsyms.c (lookup_minimal_symbol_by_pc): Use find_pc_section instead of find_pc_mapped_section. (lookup_minimal_symbol_by_pc_section): If the SECTION is NULL, do not default to the section containing PC. Fix PR gdb/1519. Index: minsyms.c =================================================================== RCS file: /cvs/src/src/gdb/minsyms.c,v retrieving revision 1.39 diff -u -r1.39 minsyms.c --- minsyms.c 11 Nov 2003 20:04:52 -0000 1.39 +++ minsyms.c 27 Jan 2004 21:24:26 -0000 @@ -355,7 +355,7 @@ /* Search through the minimal symbol table for each objfile and find the symbol whose address is the largest address that is still less - than or equal to PC, and matches SECTION (if non-null). Returns a + than or equal to PC, and matches SECTION (if non-NULL). Returns a pointer to the minimal symbol if such a symbol is found, or NULL if PC is not in a suitable range. Note that we need to look through ALL the minimal symbol tables before deciding on the symbol that @@ -374,20 +374,23 @@ struct minimal_symbol *best_symbol = NULL; struct obj_section *pc_section; - /* pc has to be in a known section. This ensures that anything beyond - the end of the last segment doesn't appear to be part of the last - function in the last segment. */ + /* PC has to be in a known section. This ensures that anything + beyond the end of the last segment doesn't appear to be part of + the last function in the last segment. */ pc_section = find_pc_section (pc); if (pc_section == NULL) return NULL; - /* If no section was specified, then just make sure that the PC is in - the same section as the minimal symbol we find. */ - if (section == NULL) - section = pc_section->the_bfd_section; - - /* FIXME drow/2003-07-19: Should we also check that PC is in SECTION - if we were passed a non-NULL SECTION argument? */ + /* NOTE: cagney/2004-01-27: Removed code (added 2003-07-19) that was + trying to force the PC into a valid section as returned by + find_pc_section. It broke IRIX 6.5 mdebug which relies on this + code returning an absolute symbol - the problem was that + find_pc_section wasn't returning an absolute section and hence + the code below would skip over absolute symbols. Since the + original problem was with finding a frame's function, and that + uses [indirectly] lookup_minimal_symbol_by_pc, the original + problem has been fixed by having that function use + find_pc_section. */ for (objfile = object_files; objfile != NULL; @@ -497,7 +500,13 @@ struct minimal_symbol * lookup_minimal_symbol_by_pc (CORE_ADDR pc) { - return lookup_minimal_symbol_by_pc_section (pc, find_pc_mapped_section (pc)); + /* NOTE: cagney/2004-01-27: This was using find_pc_mapped_section to + force the section but that (well unless you're doing overlay + debugging) always returns NULL making the call somewhat useless. */ + struct obj_section *section = find_pc_section (pc); + if (section == NULL) + return NULL; + return lookup_minimal_symbol_by_pc_section (pc, section->the_bfd_section); } --------------000906010601080300070401--