From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24676 invoked by alias); 11 Sep 2009 21:04:23 -0000 Received: (qmail 24665 invoked by uid 22791); 11 Sep 2009 21:04:23 -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 21:04:19 +0000 Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id n8BL4GUQ005331 for ; Fri, 11 Sep 2009 22:04:17 +0100 Received: from yxe29 (yxe29.prod.google.com [10.190.2.29]) by wpaz9.hot.corp.google.com with ESMTP id n8BL4ERi032605 for ; Fri, 11 Sep 2009 14:04:14 -0700 Received: by yxe29 with SMTP id 29so1797351yxe.16 for ; Fri, 11 Sep 2009 14:04:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.46.15 with SMTP id y15mr3847413anj.4.1252703053893; Fri, 11 Sep 2009 14:04:13 -0700 (PDT) In-Reply-To: References: <8ac60eac0908201340k6b759eb5o9bb73c8f473d8785@mail.gmail.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> <8ac60eac0909110029q1c88dcetdb644fa461fa545c@mail.gmail.com> Date: Fri, 11 Sep 2009 21:04:00 -0000 Message-ID: <8ac60eac0909111404x1e67a7d9wba46be99fb424c73@mail.gmail.com> Subject: Re: [patch] Speed up find_pc_section From: Paul Pluzhnikov To: Tom Tromey Cc: Pierre Muller , Joel Brobecker , Ulrich Weigand , gdb-patches ml , 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/msg00335.txt.bz2 On Fri, Sep 11, 2009 at 1:50 PM, Tom Tromey wrote: > Paul> Perhaps I should just add a sequence number to 'struct objfile'? Th= at > Paul> looks like it would almost give exact same ordering as what GDB used > Paul> before qsort+bsearch was introduced. > > Is there some benefit to the old ordering? The only benefit I see is that it was deterministic (a section from an earlier-added objfile always matched first and was returned). With current sort/filter/bsearch we don't have that. If we enter "bad state" (two sections overlap), it may happen that we sometimes return the one from earlier-added objfile, and sometimes the one from the later-added objfile. This could lead to GDB bug reports which are harder to reproduce (your qsort may produce a different final section order from my qsort even for otherwise identical inputs). > I assumed that the old approach just gave the user an arbitrary > ordering, in which case any change here is no big deal. Not completely arbitrary. > But, if there > is a benefit to the old ordering, sure, restore it. I think there is -- reproducibility of the "bad state". > How stable a sort would you want? =A0You could just fall back to the > objfile's address. =A0Or is that too awful? I don't think there is any advantage to that, as this will still lead to essentially random ordering from one system to another. Thanks, --=20 Paul Pluzhnikov