public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: ASSI <Stromeko@nexgo.de>
To: binutils@sourceware.org
Subject: Replacement for "objdump -d -l"?
Date: Mon, 07 Aug 2023 20:35:18 +0200	[thread overview]
Message-ID: <87a5v24s61.fsf@Rainer.invalid> (raw)


As detailed in bug#30725, objdump performance has gradually worsened
over the last releases to the point where it hurts.  So I'm looking for
alternatives… cygport at one point in time used llvm-objdump because it
was faster at this, but currently we don't have a new enough llvm so
that alternative is blocked.  Of particular interest is "objdump -d -l"
to produce the list of source files the object references so they can be
put into the debuginfo package.  Obviously the "-d" part is completely
superfluous towards that goal as we're not even looking at the result,
but there doesn't seem to be another way of getting the same information
without it.  So I've resigned to do an "objdump -WNl" instead and parse
that output with a small Perl script (i.e. the directory and file
tables)… with interesting results.

Firstly, something that takes over an hour across 8C/16T with the
current objdump (and over half an hour in the previous version) using
"objdump -d -l", now takes not quite three seconds (that includes the
actual dump and the parsing).  Secondly, I get way more source files
extracted with the Perl script: it seems that there are plenty of
records that reference header files that are not output via "-d -l" for
whatever reason.  I might be able to actually parse the DWARF
instructions following the tables to eliminate that difference, but
before I try to do that, I'd like to know what exactly is the criterion
for a source file to appear in the output of "objdump -d -l"?

Lastly, it seem brittle to parse the output as clearly it is meant to be
human readable and might change in future versions (aside from the fact
there doesn't seem to be a documentation of the current format for
crying out loud).  I'd be much more content with a format that was
designed to be machine readable and fully documented (again llvm has an
objdump that produces YAML).  Is there something like that in binutils I
can use?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

             reply	other threads:[~2023-08-07 18:35 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-07 18:35 ASSI [this message]
2023-08-15 14:15 ` Nick Clifton
2023-08-17 18:38   ` ASSI
2023-08-22 12:17   ` Richard Earnshaw (lists)

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=87a5v24s61.fsf@Rainer.invalid \
    --to=stromeko@nexgo.de \
    --cc=binutils@sourceware.org \
    /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).