Op dinsdag 02-06-2009 om 16:51 uur [tijdzone -0400], schreef Adam Goode: Hi Adam, Your observation is correct. The .DLL's we ship contain debug symbols. Only the static libraries (.a files) are stripped. A while ago I looked for a way to strip out the debug symbols and collect them in a -debuginfo package (like the regular Fedora packages), but it requires modification to some RPM files (scripts and tools). The script /usr/lib/rpm/find-debuginfo.sh is one of those scripts which needs adjustment. From the looks of it, three files are created: debugfiles.list, debugsources.list and debuglinks.list. It isn't clear what the contents of those files 'should' be. Next to this, also some RPM tools are called to extract the debug information like /usr/lib/rpm/debugedit and /usr/bin/eu_strip (elfutils). The debugedit tool is written in C and makes intensive use of binutils. As the use of binutils is a bit too low-level for me, I gave up trying to extract debug information from our MinGW DLL's... Maybe this information can be of use to somebody else. Regards, Erik van Pienbroek

Op woensdag 03-06-2009 om 13:09 uur [tijdzone +0200], schreef Fridrich Strba: Very interesting :) Do you also know how to load these debug files in (a win32 native) gdb? Regards, Erik van Pienbroek

Op donderdag 04-06-2009 om 13:41 uur [tijdzone +0200], schreef Fridrich Strba: Sorry for the late response, but I prepared a patch for mingw32-filesystem to add -debug subpackage support. Is it okay to commit this? I've also added a patch for one of my packages to indicate the steps needed for all mingw32 packages to get -debug subpackage support. It basically consists of two extra lines. There's one thing that needs attention: one needs to add %define __os_install_post %{_mingw32_debug_install_post} to the spec file. %global doesn't work in this case! One thing I noticed while preparing this is that there's an openSuSE buildsystem project [1] which has basically forked all our work and added more features and packages to it. I wonder why this fork was done and why features (like this -debug subpackage support) haven't been proposed upstream (to us) sooner? Several packages there also have their ChangeLog stripped away so the history can't be viewed anymore.. Regards, Erik van Pienbroek [1]: https://build.opensuse.org/project/show?project=windows%3Amingw% 3Awin32

Op maandag 22-06-2009 om 09:57 uur [tijdzone +0100], schreef Richard W.M. Jones: Done, with the change Daniel suggested (-debuginfo subpackage) Here you go Regards, Erik van Pienbroek

Op donderdag 25-06-2009 om 18:41 uur [tijdzone +0300], schreef Kalev Lember: Hi, I finally had some time to test the -debuginfo subpackages out on a native Win32 environment. For this I used a gdb.exe which I compiled some time ago [1] (is this package welcome in Fedora as it's only an executable?). For my testing I creating a small test application consisting of the following code: --- #include <glib.h> int main() { g_print("Hello world\n"); return 0; } --- Test 1: For this test I created a new folder and put the .exe and libglib-2.0-0.dll in it. After opening the .exe in gdb I set a breakpoint on 'g_print' and run the program. Result: gdb breaked fine on the g_print call, but didn't show any additional information (as expected) Test 2: For this test I also added the file libglib-2.0-0.dll.debug in the same folder and performed the same steps in gdb. Result: gdb breaked fine on the g_print call and showed that the code can be found in the file ../.../glib/gmessages.c on line 984 (as expected). When the gdb command 'list' is executed, I get a 'No such file or directory' warning which is also as expected Test 3: The same as test 2, but now I added the file gmessages.c from the glib source code and put it in the same directory. Result: The gdb command 'list' now shows the contents of the gmessages.c file Test 4: The same as test 2, but I created a new folder (..\..\glib) and put the file gmessages.c there Result: The gdb command 'list' now shows the contents of the gmessages.c file I also did the same series of tests with a small test application based on libgnurx. The only difference I found was that gdb tried to search for regcomp.c (without any extra paths). So where does this bring us? - Line information can be retrieved by putting the dll.debug file in the same directory as the regular .dll - Source information can be retrieved by putting the source files in the same directory as the executable (or in a relative path if that's the case) If we also want to bundle the source files with our packages, we need to find a way to detect all the source code files which are used by each individual library. For native Linux this is done by the RPM tool 'debugedit' (/usr/lib/rpm/debugedit). However, we can't use this tool right now as it only works on ELF binaries and I don't have the experience to adjust it to work on PE binaries (what's used on Win32). Maybe somebody else here is interested in hacking RPM's debugedit ? Regards, Erik van Pienbroek [1]: http://www.ftd4linux.nl/contrib/gdb.exe

Op vrijdag 03-07-2009 om 19:57 uur [tijdzone +0100], schreef Richard W.M. Jones: I'm not sure whether the Fedora MinGW project can make advantage of that feature as most debugging will be done on native Win32 environments. The only use case I can think of is by performing a remote debug session (linux host to a win32 target) though I haven't tried doing this yet. Might be worth more research. Regards, Erik van Pienbroek

On Mon, Jun 22, 2009 at 01:57:52AM +0200, Erik van Pienbroek wrote: It looks ok, but the package should be called '-debuginfo' not just '-debug', so that they end up in the correct YUM repositories. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Op maandag 22-06-2009 om 13:48 uur [tijdzone +0200], schreef Kevin Kofler: While researching that situation I've discovered that the wrong RPM variable is being overridden. Instead of __os_install_post the variable __debug_install_post should be used. When __os_install_post is used, stripping of the static libraries doesn't occur anymore. So the new line should be: %define __debug_install_post %{_mingw32_debug_install_post} What's the best way to rectify this in the mingw32-filesystem package as the ChangeLog entry for mingw32-filesystem-52-1.fc12 mentions the wrong comment? See http://koji.fedoraproject.org/koji/buildinfo?buildID=111324 On with the mixed packages: I've experimented a bit with producing debuginfo subpackages for both the native and mingw bits of mingw32-nsis and came up with this: %define __debug_install_post \ %{_rpmconfigdir}/find-debuginfo.sh %{?_missing_build_ids_terminate_build:--strict-build-id} %{?_find_debuginfo_opts} "%{_builddir}/%{?buildsubdir}" \ mkdir %{_builddir}/%{?buildsubdir}/tmp \ /usr/lib/rpm/mingw32-find-debuginfo.sh %{_builddir}/%{?buildsubdir}/tmp \ cat %{_builddir}/%{?buildsubdir}/tmp/debugfiles.list >> %{_builddir}/%{?buildsubdir}/debugfiles.list \ rm -rf %{_builddir}/%{?buildsubdir}/tmp \ %{nil} With this instruction, the debuginfo for the native bits will be generated first. Next the debuginfo for the mingw bits will be created. The debugfiles.list which is produced in this step will be saved to a temporary location. Next, the two debugfiles.list files are merged together. For this type of packages (where BuildArch != noarch), it isn't necessary to use the %{_mingw32_debug_package} macro as that's done automatically by RPM. Please note that the current version of mingw32-nsis is compiled without debug symbols (the mingw bits) so no mingw files are added to the -debuginfo subpackage right now. Regards, Erik van Pienbroek

Erik van Pienbroek wrote: I know, this is intentionally disabled right now because we didn't have support for extracting debuginfo and so the debuginfo bloats the installers. That said, I doubt the debuginfo extraction does the right thing (if it works at all) on the NSIS stubs: they're basically EXE files, but without the extension. NSIS builds the setup.exe by taking the stub, changing a few bytes in the header and appending the payload to it. So will the extracted debuginfo from the stubs be of any use? Another reason I disabled the debugging information for the stubs is that the above process gets confused by the presence of debugging sections in the stub: with those sections present, the header editing generates corrupt executables which crash or trigger errors in tools like UPX or objdump (and may also have other ill side effects). If debuginfo extraction works, that would of course solve this particular issue, as well as the bloat issue. Kevin Kofler