public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Emile Snyder <binutils@talentcodeworks.com>
To: binutils@sources.redhat.com
Subject: objdump -d --line-numbers performance question
Date: Sat, 26 Feb 2005 08:25:00 -0000	[thread overview]
Message-ID: <1109363210.2119.229.camel@basalt> (raw)

[-- Attachment #1: Type: text/plain, Size: 1581 bytes --]

Hello all,

In one project I work on there's some scripts which we use to do
debugging that use objdump to get at debugging symbol info to decode
backtrace dumps from the program.  The application binary is ~50MB when
built with debugging info, and when we moved from developing on RedHat
7.3 to RH 9 or later, the objdump time went through the roof.

I grabbed a binutils-2.14 tarball, and spent a little time digging. 
oprofile reports that some huge proportion of the time is spent in the
bfd/elf.c:elf_find_function() call, which is being called (with some
intermediates) by binutils/objdump.c:show_line().

Looking at elf_find_function() it jumps out that it's doing a linear
search through the entire set of symbols every time it's called.  But
show_line() has access to find_symbol_for_address which does a binary
search on a sorted set of symbols.

So.  The attached patch uses find_symbol_for_address() in show_line(),
and then passes down a fake asymbol** list consisting of just the found
symbol and a null end marker.  So far it always produces identical
'objdump -d --line-numbers' output for me as the stock objdump, but my
run time on one representative file has gone from ~2 hours to ~4
minutes.

Does this look right?  If not, can anyone give me some pointers on the
right way to try to optimize things?

Thanks,
-emile


+----------------------------------------------------------------------
this wine is particularly heavy, and is mostly recommended for
hand-to-hand combat. -- Eric Idle 
+----------------------------------------------------------------------

[-- Attachment #2: binutils-2.14.objdumppatch --]
[-- Type: text/x-patch, Size: 1027 bytes --]

diff -Naur binutils-2.14/binutils/objdump.c binutils-2.14-modified/binutils/objdump.c
--- binutils-2.14/binutils/objdump.c	2003-03-31 16:32:47.000000000 -0800
+++ binutils-2.14-modified/binutils/objdump.c	2005-02-25 12:02:43.617595584 -0800
@@ -980,13 +980,22 @@
   const char *filename;
   const char *functionname;
   unsigned int line;
+  asymbol *foundsym;
+  asymbol *mocksyms[2];
+  long symplace;
 
   if (! with_line_numbers && ! with_source_code)
     return;
 
-  if (! bfd_find_nearest_line (abfd, section, syms, addr_offset, &filename,
-			       &functionname, &line))
-    return;
+  foundsym = find_symbol_for_address(abfd, section, 
+                                     section->vma + addr_offset, 
+                                     FALSE, &symplace);
+  mocksyms[0] = foundsym;
+  mocksyms[1] = NULL;
+
+  if (! bfd_find_nearest_line (abfd, section, mocksyms, addr_offset, &filename,
+  			       &functionname, &line))
+      return;
 
   if (filename != NULL && *filename == '\0')
     filename = NULL;

             reply	other threads:[~2005-02-25 20:25 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-26  8:25 Emile Snyder [this message]
2005-03-01 11:11 ` Nick Clifton
2005-03-02 15:27   ` Emile Snyder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1109363210.2119.229.camel@basalt \
    --to=binutils@talentcodeworks.com \
    --cc=binutils@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).