Replacement for "objdump -d -l"?

Replacement for "objdump -d -l"?

[ASSI]

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

Re: Replacement for "objdump -d -l"?

[Nick Clifton]

Hi ASSI,

> Lastly, it seem brittle to parse the output as clearly it is meant to be
> human readable and might change in future versions

Correct.

> (aside from the fact
> there doesn't seem to be a documentation of the current format for
> crying out loud).

Because the output format has evolved rather than being specified by a standard.

But to be fair, the output format does not change that much, and
it could be documented if there really was a need.


> 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?

No, but it would be nice to have.

A fixed, extensible, machine readable output format would be much appreciated
as a new feature for objdump.  All it really needs is someone with the time,
knowledge and motivation to write it.

Cheers
   Nick

Re: Replacement for "objdump -d -l"?

[ASSI]

Nick Clifton via Binutils writes:
> But to be fair, the output format does not change that much, and
> it could be documented if there really was a need.

I've implemented a Perl script that just extracts the file and directory
tables from the -WNl dump and checks which of these actually get
referenced by line number statements.  The latter part is necessary
since there are more files in the tables than are actually used in line
number statements.  I still extract more files than what I am getting
from "objdump -dl", these extras seem to be instances where the same
address in the disassembly has multiple views associated (not analysed,
but from the files involved these might be resulting from macro
expansions).  I have not yet figured out which of these views is the one
that ends up in the disassembly with line numbers dump, but for the
prupose of debugging it seems I should actually keep debug sources for
all views the debugger might encounter.  The other snag I've hit is
relative directories in the directory table, but with the examples I've
seen so far these resolve relative to directory entry #0 (which is
otherwise unreferenced by file table entries).


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

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Replacement for "objdump -d -l"?

[Richard Earnshaw (lists)]

On 15/08/2023 15:15, Nick Clifton via Binutils wrote:
> Hi ASSI,
> 
>> Lastly, it seem brittle to parse the output as clearly it is meant to be
>> human readable and might change in future versions
> 
> Correct.
> 
>> (aside from the fact
>> there doesn't seem to be a documentation of the current format for
>> crying out loud).
> 
> Because the output format has evolved rather than being specified by a 
> standard.
> 
> But to be fair, the output format does not change that much, and
> it could be documented if there really was a need.
> 
> 
>> 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?
> 
> No, but it would be nice to have.
> 
> A fixed, extensible, machine readable output format would be much 
> appreciated
> as a new feature for objdump.  All it really needs is someone with the 
> time,
> knowledge and motivation to write it.
> 
> Cheers
>    Nick
> 

I think if we were ever to specify a machine-readable format for the 
output, we'd probably want to use some structured dumping format, rather 
than try to specify the current format more precisely.  That would avoid 
a lot of parsing problems for readers and also give us a chance of being 
able to add new features without breaking every tool that reads the output.

R.