Re: [patch] Speed up dwarf2_frame_find_fde

[Paul Pluzhnikov <ppluzhnikov@google.com>]

On Tue, Aug 4, 2009 at 11:17 AM, Tom Tromey<tromey@redhat.com> 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