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.
