From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28480 invoked by alias); 4 Aug 2009 19:08:34 -0000 Received: (qmail 28470 invoked by uid 22791); 4 Aug 2009 19:08:33 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 04 Aug 2009 19:08:24 +0000 Received: from spaceape8.eur.corp.google.com (spaceape8.eur.corp.google.com [172.28.16.142]) by smtp-out.google.com with ESMTP id n74J8LC6000788 for ; Tue, 4 Aug 2009 12:08:22 -0700 Received: from qyk17 (qyk17.prod.google.com [10.241.83.145]) by spaceape8.eur.corp.google.com with ESMTP id n74J8IGf009844 for ; Tue, 4 Aug 2009 12:08:19 -0700 Received: by qyk17 with SMTP id 17so5342391qyk.9 for ; Tue, 04 Aug 2009 12:08:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.96.13 with SMTP id f13mr2123886qcn.36.1249412898482; Tue, 04 Aug 2009 12:08:18 -0700 (PDT) In-Reply-To: References: <20090721223129.85D1F76BC0@localhost> <8ac60eac0907221324n28e246c1k5e62f79973955ae@mail.gmail.com> Date: Tue, 04 Aug 2009 19:08:00 -0000 Message-ID: <8ac60eac0908041208g477503e9n8079bd8df935b8b1@mail.gmail.com> Subject: Re: [patch] Speed up dwarf2_frame_find_fde From: Paul Pluzhnikov To: tromey@redhat.com Cc: Andreas Schwab , gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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-08/txt/msg00061.txt.bz2 On Tue, Aug 4, 2009 at 11:17 AM, Tom Tromey wrote: > Paul> +static int > Paul> +qsort_fde_cmp (const void *a, const void *b) > Paul> +{ > Paul> + struct dwarf2_fde *aa = *(struct dwarf2_fde **)a; > Paul> + struct dwarf2_fde *bb = *(struct dwarf2_fde **)b; > Paul> + if (aa->initial_location == bb->initial_location) > Paul> + /* Put eh_frame entries after debug_frame ones. */ > Paul> + return aa->eh_frame_p - bb->eh_frame_p; > > I don't understand this comment. Before the patch: - /* First add the information from the .eh_frame section. That way, - the FDEs from that section are searched last. */ IOW, we prefer .debug_frame entries to .eh_frame ones. After the patch, .eh_frame entries are sorted after .debug_frame ones in the fde_table, and are then duplicate-eliminated when the final fde_table is constructed here: + /* Since we'll be doing bsearch, squeeze out identical (except for + eh_frame_p) fde entries so bsearch result is predictable. */ + for (i = 0, j = 0; j < fde_table.num_entries; ++i) + { + const int k = j; + + obstack_grow (&objfile->objfile_obstack, &fde_table.entries[j], + sizeof (fde_table.entries[0])); + while (++j < fde_table.num_entries + && (fde_table.entries[k]->initial_location == + fde_table.entries[j]->initial_location)) + /* Skip. */; + } > I thought perhaps there would be some reason to do this -- but then it > seems like the bsearch comparison function ought to have similar logic. > Could you explain it? Since the .eh_frame entries that were "pre-empted" by the .dwarf_frame ones don't even appear in the final table, bsearch_fde_cmp doesn't need special handling for them. Thanks, -- Paul Pluzhnikov