From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30604 invoked by alias); 8 Sep 2009 21:17:08 -0000 Received: (qmail 30536 invoked by uid 22791); 8 Sep 2009 21:17:07 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 08 Sep 2009 21:16:58 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 115652BABE1; Tue, 8 Sep 2009 17:16:56 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Dyk2KKA2Jxu5; Tue, 8 Sep 2009 17:16:56 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id B7BFC2BAB4E; Tue, 8 Sep 2009 17:16:55 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id EC28CF589B; Tue, 8 Sep 2009 14:16:49 -0700 (PDT) Date: Tue, 08 Sep 2009 21:17:00 -0000 From: Joel Brobecker To: Paul Pluzhnikov Cc: Ulrich Weigand , Ulrich Weigand , gdb-patches ml , Tom Tromey , Jan Kratochvil Subject: Re: What should we do re: "[patch] Speed up find_pc_section" Message-ID: <20090908211649.GU30677@adacore.com> References: <8ac60eac0908201340k6b759eb5o9bb73c8f473d8785@mail.gmail.com> <200908211130.n7LBUCJc011108@d12av02.megacenter.de.ibm.com> <8ac60eac0908231548x135edf2doa04fa59a49455bcd@mail.gmail.com> <8ac60eac0908260020l4200cf84v2686a76b5858d13@mail.gmail.com> <8ac60eac0909021002q74acb916kcd5d4e28ae5fb370@mail.gmail.com> <20090908183649.GS30677@adacore.com> <8ac60eac0909081315o4d0a4d8bydf8b8df78d0a2eaa@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8ac60eac0909081315o4d0a4d8bydf8b8df78d0a2eaa@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) 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-09/txt/msg00227.txt.bz2 That was a very informative answer, thank you. > Rather, all the .o files are relocatable, so they all start at zero > and overlap each other. After having applied your patch, the debugger reports overlaps between the exec file and the .o files, not overlaps between .o files: warning: Unexpected overlap between section `.data' from `/lensk.a/users/brobecke/ex/a' [0x100014000, 0x10001e850) and section `.data' from `a-except.o' [0x100014020, 0x100014031) warning: Unexpected overlap between section `.data' from `/lensk.a/users/brobecke/ex/a' [0x100014000, 0x10001e850) and section `.data' from `s-except.o' [0x100014199, 0x10001419a) > I don't believe there is non-trivial effort in fixing this. > In fact, I believe (but have not yet confirmed) this may just be fixed by > the other patch: > http://sourceware.org/ml/gdb-patches/2009-08/msg00437.html I can confirm that this appears to fix the issue. The only complaint I have with this patch is that it emits warnings each and every overlap that it finds. Unfortunately, even for the smallest of programs in Ada, you have a dozen object files involved (because of the GNAT runtime, usually involving exceptions, etc). So I would suggest using a complaint instead of a warning (this is similar to what we do with invalid DWARF data that we find, I believe). > Note that the separate '*.o' addition has its own bug: the sections from > all the .o files are added, but never removed (and this is unrelated to > my patch in any way). This is in fact why Tristan said that my earlier patch > "works, but makes GDB spend 10 minutes in CPU loop". Right - that's the part that would be less trivial to fix, hence the suggestion to leave this for 7.1. > Now that I am back from vacation, I will confirm that the > gdb-find_pc_section-20090825.txt from > http://sourceware.org/ml/gdb-patches/2009-08/msg00437.html > in fact does also fix MacOS, and will work on eliminating unbounded growth > of the separate .o files. > > If someone could just review the above patch, we'll be good to go :=) I'll try to review. Not sure if I'm competent or not yet, though. -- Joel