Op woensdag 03-06-2009 om 13:09 uur [tijdzone +0200], schreef Fridrich Strba:

Check this script that I use in my openSUSE build system to extract the debug information.

Cheers

Fridrich

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:

Just install them side by side with the binaries, like something.dll.debug in the same directory as something.dll

The gnu debug link information will tell gdb on win32 where to look for the symbols.

Cheers

Fridrich

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:

On Mon, Jun 22, 2009 at 01:57:52AM +0200, Erik van Pienbroek wrote:

...

Sorry for the late response, but I prepared a patch for mingw32-filesystem to add -debug subpackage support. Is it okay to commit this?

Yes, but I think we should only commit this to Rawhide.

Done, with the change Daniel suggested (-debuginfo subpackage)

...

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.

Got a patch for mingw32-example.spec?

Here you go

Regards,

Erik van Pienbroek

Op donderdag 25-06-2009 om 18:41 uur [tijdzone +0300], schreef Kalev Lember:

Erik van Pienbroek wrote:

...

Op maandag 22-06-2009 om 09:57 uur [tijdzone +0100], schreef Richard W.M. Jones:

...

On Mon, Jun 22, 2009 at 01:57:52AM +0200, Erik van Pienbroek wrote:

...

Sorry for the late response, but I prepared a patch for mingw32-filesystem to add -debug subpackage support. Is it okay to commit this?

Yes, but I think we should only commit this to Rawhide.

Done, with the change Daniel suggested (-debuginfo subpackage)

Native -debuginfo packages usually also contain source files to be able to view source code when debugging with gdb. For example:

$ rpm -ql libusb-debuginfo

<snip> /usr/lib/debug/usr/lib/libusbpp.so.debug /usr/src/debug/libusb-0.1.12 /usr/src/debug/libusb-0.1.12/descriptors.c /usr/src/debug/libusb-0.1.12/error.c <snip>

However, our mingw32 debuginfo packages only contain the debug dll. Is the lack of source files a problem for Windows debugging? I don't have a Windows setup to try it out.

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:

On Thu, Jul 02, 2009 at 10:26:13PM +0200, Erik van Pienbroek wrote:

...

• 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)

Also consider how this will get along with the following feature:

https://fedoraproject.org/wiki/Features/DebuginfoFS

We might need to use symlinks to ensure that the files we add are 'really' located in the ordinary debuginfo directories. If that will work ...

Rich.

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:

Op donderdag 04-06-2009 om 13:41 uur [tijdzone +0200], schreef Fridrich Strba:

...

Just install them side by side with the binaries, like something.dll.debug in the same directory as something.dll

The gnu debug link information will tell gdb on win32 where to look for the symbols.

Cheers

Fridrich

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!

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

Op maandag 22-06-2009 om 13:48 uur [tijdzone +0200], schreef Kevin Kofler:

Erik van Pienbroek wrote:

...

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!

Does this work on packages which are mixed native and cross such as mingw32-nsis?

And it should indeed be -debuginfo, not -debug.

    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:

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.

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