From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7204 invoked by alias); 6 Feb 2004 18:59:23 -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 7182 invoked from network); 6 Feb 2004 18:59:22 -0000 Received: from unknown (HELO localhost.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 6 Feb 2004 18:59:22 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id BA2C82B92; Fri, 6 Feb 2004 13:59:16 -0500 (EST) Message-ID: <4023E404.2090407@gnu.org> Date: Fri, 06 Feb 2004 18:59: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: Elena Zannoni , Adam Fedor Cc: "gdb-patches@sources.redhat.com" Subject: Re: [rfa/symtab] Move find_pc_section call to lookup_minimal_symbol_by_pc References: <4016E401.2050001@gnu.org> <16409.26976.292424.689823@localhost.redhat.com> <1075433366.29218.7.camel@localhost.localdomain> <16417.28535.67901.37314@localhost.redhat.com> <40217AE6.9060500@gnu.org> Content-Type: multipart/mixed; boundary="------------040100010205020702010605" X-SW-Source: 2004-02/txt/msg00122.txt.bz2 This is a multi-part message in MIME format. --------------040100010205020702010605 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-length: 1068 > Um, I'm not sure what is happening. My GNU/Linux amd64 box appears to pass both times: I've found the right machine (YelloDog 3.0), the attached appears to work on both yellow dog and IRIX (and Fedora Core). The new patch modifies find_pc_partial_function supply the PC's section when available. Look ok? The problem was that the symbol lookup was finding a symbol from a previous section, instead of no symbol in the current section. That leads to this test (using Joe's rewrite): > + if (ecs->stop_func_name == NULL > + && step_over_calls == STEP_OVER_UNDEBUGGABLE) > + { > + /* We couldn't determine where we stopped, so we just stepped > + inside undebuggable code. Since we want to step over this > + kind of code, we keep going until the inferior returns from > + the current function. */ > + handle_step_into_function (ecs); > + return; > + } not triggering. ->stop_func_name had a non-NULL but bogus symbol name. ok? Andrew PS: I think GDB has a few too many symbol lookup interfaces :-( --------------040100010205020702010605 Content-Type: text/plain; name="diffs" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="diffs" Content-length: 4645 2004-02-06 Andrew Cagney * blockframe.c (find_pc_partial_function): If find_pc_overlay fails, try find_pc_section. Fix PR c++/1267. * 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 symtab/1519. Index: blockframe.c =================================================================== RCS file: /cvs/src/src/gdb/blockframe.c,v retrieving revision 1.87 diff -u -r1.87 blockframe.c --- blockframe.c 4 Feb 2004 16:34:51 -0000 1.87 +++ blockframe.c 6 Feb 2004 18:42:16 -0000 @@ -507,10 +507,24 @@ find_pc_partial_function (CORE_ADDR pc, char **name, CORE_ADDR *address, CORE_ADDR *endaddr) { - asection *section; + struct bfd_section *bfd_section; - section = find_pc_overlay (pc); - return find_pc_sect_partial_function (pc, section, name, address, endaddr); + /* To ensure that the symbol returned belongs to the correct setion + (and that the last [random] symbol from the previous section + isn't returned) try to find the section containing PC. First try + the overlay code (which by default returns NULL); and second try + the normal section code (which almost always succeeds). */ + bfd_section = find_pc_overlay (pc); + if (bfd_section == NULL) + { + struct obj_section *obj_section = find_pc_section (pc); + if (obj_section == NULL) + bfd_section = NULL; + else + bfd_section = obj_section->the_bfd_section; + } + return find_pc_sect_partial_function (pc, bfd_section, name, address, + endaddr); } /* Return the innermost stack frame executing inside of BLOCK, 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 6 Feb 2004 18:42:16 -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); } --------------040100010205020702010605--