[PATCH] Re: stripping of DLLs?

[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