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
