Re: [cygport] enabling a replacement for "objdump -d -l"

[Marco Atzeri <marco.atzeri@gmail.com>]

On 18/02/2024 20:51, ASSI via Cygwin-apps wrote:
> 
> Cygport uses "objdump -d -l" to extract the list of source files that
> need to be copied into the debuginfo package.  This operation triggers
> some O(N²) or even higher complexity and in addition has been getting
> slower in recent binutils releases due to more and more information
> being put into the object files.  For gcc-11 extracting the debug source
> files takes up to 45 minutes per executable (up from about 15 minutes
> until 2.39) and for gcc-13 (with about 1.5 times the number of lines to
> extract) it is already taking more than two hours.  So if you just
> package gcc-13 using a single thread you'd be looking on the order of 20
> hours wall clock time, which is unacceptable.
> 
> The deassembly implied by the "-d" (which is not the part that has the
> superlinear complexity btw, but produces a baseline of 2 hours single
> thread runtime all by itself) is also unnecessary to extract just the
> filenames of the source files as we throw away the location information
> anyway and so I've written a small parser that works on the DWARF dump
> instead (which can be produced in linear time with a very small scaling
> factor, so practically constant time even for very large executables).
> Unfortunately binutils does not yet offer a machine readable format for
> these dumps, but parsing the text is not too difficult even though the
> format is undocumented.  The DWARF-5 documentation isn't the most
> enjoyable read, but it was helpful enough to figure it all out.  I've
> also integrated the filtering of unrelated source file information (from
> system headers and external libraries).  The end result is the same
> runtime as before on small object files, a factor up to 100 speedup for
> medium sized object files and speedups in the several thousands range
> for large sized ones (or a total single-thread runtime of less than 20
> seconds for gcc-13).
> 
>
> Integration into cygport is made configurable via a variable to be set
> in .cygportrc for instance in order to easily revert back to the
> original objdump invocation if necessary.  I've been producing packages
> with that setup for a while now and have not noticed any errors.  In
> principle the new parser actually produces more complete output as there
> can be multiple line number statements and hence source files per
> location, but objdump only lists one of them in the disassembly (at
> least sometimes).  In practise I haven't found a package until now where
> the final list (after filtering) is different.
> 

if works should not be the default ?
Reducing that time is very interesting for the big stuff


> 
> Regards,
> Achim.

Thanks
Marco