From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23203 invoked by alias); 21 Aug 2009 11:30:26 -0000 Received: (qmail 23193 invoked by uid 22791); 21 Aug 2009 11:30:24 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mtagate4.de.ibm.com (HELO mtagate4.de.ibm.com) (195.212.29.153) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 21 Aug 2009 11:30:17 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.14.3/8.13.8) with ESMTP id n7LBUEnC175018 for ; Fri, 21 Aug 2009 11:30:14 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n7LBUEjC1892400 for ; Fri, 21 Aug 2009 13:30:14 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n7LBUDZE011128 for ; Fri, 21 Aug 2009 13:30:14 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id n7LBUCJc011108; Fri, 21 Aug 2009 13:30:12 +0200 Message-Id: <200908211130.n7LBUCJc011108@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Fri, 21 Aug 2009 13:30:12 +0200 Subject: Re: [patch] Speed up find_pc_section To: ppluzhnikov@google.com (Paul Pluzhnikov) Date: Fri, 21 Aug 2009 12:36:00 -0000 From: "Ulrich Weigand" Cc: Ulrich.Weigand@de.ibm.com (Ulrich Weigand), gdb-patches@sourceware.org (gdb-patches ml), tromey@redhat.com (Tom Tromey) In-Reply-To: <8ac60eac0908201340k6b759eb5o9bb73c8f473d8785@mail.gmail.com> from "Paul Pluzhnikov" at Aug 20, 2009 01:40:11 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-08/txt/msg00341.txt.bz2 Paul Pluzhnikov wrote: > I believe the crash at load should be gone now, and some debugging will > be possible, though find_pc_section will fail to find any overlay section > which find_pc_mapped_section doesn't find. I think that's still better > than what GDB was doing before under these conditions: finding a "random" > overlapping overlay section. With this patch, GDB no longer crashes, but some overlay tests fail anyway. The problem is related to resolving an address in an overlay back to a symbol via lookup_minimal_symbol_by_pc_section_1. The caller passes the correct PC (VMA value) and overlay section to this routine, but the first thing the routine does is: /* 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; The new find_pc_section logic now returns NULL as the PC is in an overlay section, which is not in the section map. I think this routine needs to be fixed to take into account the section it is passed as argument, probably along the following lines: Index: gdb/minsyms.c =================================================================== RCS file: /cvs/src/src/gdb/minsyms.c,v retrieving revision 1.66 diff -u -p -r1.66 minsyms.c --- gdb/minsyms.c 28 Jun 2009 00:20:22 -0000 1.66 +++ gdb/minsyms.c 21 Aug 2009 11:16:26 -0000 @@ -457,7 +457,7 @@ lookup_minimal_symbol_by_pc_section_1 (C struct objfile *objfile; struct minimal_symbol *msymbol; struct minimal_symbol *best_symbol = NULL; - struct obj_section *pc_section; + struct obj_section *pc_section = section; enum minimal_symbol_type want_type, other_type; want_type = want_trampoline ? mst_solib_trampoline : mst_text; @@ -466,7 +466,8 @@ lookup_minimal_symbol_by_pc_section_1 (C /* 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) + pc_section = find_pc_section (pc); if (pc_section == NULL) return NULL; (A cleaner fix might be to fix all callers to never pass in a NULL section argument --most already don't-- and simply rely on it.) With this patch in addition to yours, all overlay tests pass again on spu-elf. I'm still not completely happy about the assertions you added. An assertion failure is supposed to be an indication of a bug in GDB -- it should never be possible to trigger the assertion just by providing particular user input (this includes the binary file). If for whatever reason the user provides a binary that has overlapping section that are not recognized as overlays by your logic, you'll still run into the failure ... In other places where we detect weird contents of the binary (e.g. in the DWARF data), we issue a "complaint" and then try to continue. Maybe you should do the same here: if you find overlapping sections, issue a complaint and then continue, while ignoring those sections. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com