From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6063 invoked by alias); 11 Sep 2009 07:29:31 -0000 Received: (qmail 6053 invoked by uid 22791); 11 Sep 2009 07:29:30 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_57,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 11 Sep 2009 07:29:26 +0000 Received: from zps38.corp.google.com (zps38.corp.google.com [172.25.146.38]) by smtp-out.google.com with ESMTP id n8B7TMPv031391 for ; Fri, 11 Sep 2009 08:29:23 +0100 Received: from ywh5 (ywh5.prod.google.com [10.192.8.5]) by zps38.corp.google.com with ESMTP id n8B7TK4G021536 for ; Fri, 11 Sep 2009 00:29:20 -0700 Received: by ywh5 with SMTP id 5so1252520ywh.4 for ; Fri, 11 Sep 2009 00:29:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.193.25 with SMTP id v25mr2692699anp.132.1252654159979; Fri, 11 Sep 2009 00:29:19 -0700 (PDT) In-Reply-To: <000c01ca32ac$0ca9f8b0$25fdea10$@u-strasbg.fr> References: <8ac60eac0908201340k6b759eb5o9bb73c8f473d8785@mail.gmail.com> <200908211130.n7LBUCJc011108@d12av02.megacenter.de.ibm.com> <8ac60eac0908231548x135edf2doa04fa59a49455bcd@mail.gmail.com> <8ac60eac0908260020l4200cf84v2686a76b5858d13@mail.gmail.com> <20090909055824.GB11738@adacore.com> <8ac60eac0909101036r101263e7qd11c1a69f13008f1@mail.gmail.com> <20090910182952.GK20694@adacore.com> <8ac60eac0909101829g5384d665gdab27526fe95c27c@mail.gmail.com> <000c01ca32ac$0ca9f8b0$25fdea10$@u-strasbg.fr> Date: Fri, 11 Sep 2009 07:29:00 -0000 Message-ID: <8ac60eac0909110029q1c88dcetdb644fa461fa545c@mail.gmail.com> Subject: Re: [patch] Speed up find_pc_section From: Paul Pluzhnikov To: Pierre Muller Cc: Joel Brobecker , Ulrich Weigand , gdb-patches ml , Tom Tromey , Jan Kratochvil Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-IsSubscribed: yes 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/msg00301.txt.bz2 On Thu, Sep 10, 2009 at 11:49 PM, Pierre Muller w= rote: > The patch looks OK (not that I have any say on this), > but I am still puzzled by what can happen if > you have overlapping sections in the end. At that point GDB is in a bad state, and *may* not work right. Further, since we are now doing complaint() instead of warning(), the fact that GDB is in a bad state is not immediately obvious. > =A0Is the CORE_ADDR to section mapping still > deterministic in that case? Depends on what you mean by that. The mapping is deterministic for a given set of objfiles, but may change when the set changes (even if a new objfile does not have any sections "covering" CORE_ADDR for which the mapping will change). That is because qsort is not a stable sort. I wonder if it makes sense to modify qsort_cmp() like this: if (sect1_addr < sect2_addr) return -1; else if (sect1_addr > sect2_addr) return 1; - return 0; + if (sect1->objfile->mtime < sect2->objfile->mtime) return -1; + if (sect1->objfile->mtime > sect2->objfile->mtime) return 1; + return 0; } to try to make the sort order for sections starting at the same address more stable. This attempt could still fail if the two object files were copied together and have the same mtime. Perhaps I should just add a sequence number to 'struct objfile'? That looks like it would almost give exact same ordering as what GDB used before qsort+bsearch was introduced. > =A0Using binary search for ill order item > can lead to different results if you add > items to the list, no? All overlaps are removed in filter_overlapping_sections, before the first binary search is performed. > =A0And I suspect that dynamic loading of > library can add items to the list with running > a debuggee, thus leading to a different result > before and after that loading for the same CORE_ADDR. That is correct. > =A0Shouldn't we by brute force shorten one of the two > overlapping sections to remove that error? filter_overlapping_sections simply removes one of such sections from the ma= p. > =A0If I understood your patch correctly, > it doesn't do that for now. > =A0Please tell me if I am wrong. > > Adding a simple > =A0 =A0 =A0 =A0 obj_section_endaddr (sect1):=3D sect2_addr; > after the complaint should be enough to > be sure that the binary search is deterministic, no? The binary search (I believe) is already deterministic, and modifying the_bfd_section (where obj_section_endaddr comes from) "behind libbfd's back" strikes me as very undesirable. Cheers, --=20 Paul Pluzhnikov