[Bug binutils/29505] xxx-w64-mingw32-objdump takes a long time to scan pe binaries for debug information

[ralf.habacker at freenet dot de]

https://sourceware.org/bugzilla/show_bug.cgi?id=29505

--- Comment #17 from Ralf Habacker <ralf.habacker at freenet dot de> ---
(In reply to Nick Clifton from comment #14)
> I am guessing that such an option would not make a lot of difference,
> since the debug information will still have to be loaded and scanned.
> 
> But that is not to say that it will not work, just that I am doubtful.

Under Linux, gcc supports the storage of debug symbols in a separate debug file 

https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html

> -gsplit-dwarf

> If DWARF debugging information is enabled, separate as much debugging 
> >information as possible into a separate output file with a .dwo extension. 
> >This option allows the build system to avoid linking files with debug 
> information

Would it be possible to extend ld so that something like this would also work
for mingw targets ? 

mingw binaries are of the type

file /usr/i686-w64-mingw32/sys-root/mingw/bin/libdbus-1-3.dll 
/usr/i686-w64-mingw32/sys-root/mingw/bin/libdbus-1-3.dll: PE32 executable (DLL)
(console) Intel 80386, for MS Windows

and the debug files created with objcopy are also of this type:

file /usr/i686-w64-mingw32/sys-root/mingw/bin/lib-dbus-1-3.dll.debug
/usr/i686-w64-mingw32/sys-root/mingw/bin/libdbus-1-3.dll.debug: PE32 executable
(DLL) (console) Intel 80386, for MS Windows

In my opinion, ld should receive an additional parameter for this case in order
to activate this procedure. A debug output file would have to be created and
the debug information stored in it, instead of in the generated binary, from
which the debug information would later have to be extracted in an extra step.

-- 
You are receiving this mail because:
You are on the CC list for the bug.