This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: add -debuginfo packages

Sorry for not getting back to this earlier.

On 04/08/2009 13:58, Reini Urban wrote:
Rather than stripping our exe's and dll's I suggest to strip the debug
info into
seperate /usr/lib/debug/path/file.dbg and package them seperately in -debuginfo
packages such as with fedora.

On any error which requires user-side debugging these symbols can be used
by gdb (--symbols=SYMFILE) easily.

dumper should use them too.
Is this a good idea?

At least in theory, certainly. As for implementation:

1) Right now, cygport default CFLAGS="-O2 -pipe". Adding -g is easy enough, but how will -O2 affect the debug info? (We really don't want to use -O0 for distro packages, do we?)

2) I know that on Linux, -fomit-frame-pointer breaks debugging on x86 (but not on amd64 or other arches). Some packages add this themselves for optimization, and some outright need it for their asm code (ffmpeg comes to mind). We then have a question of performance vs. debugging, so if you can only have one, which takes priority?

3) Is using /usr/lib/debug feasible? I've only ever seen .dbg files placed in the same directory as the .exe/.dll.

Below is the cygport function which can replace __prepstrip.
I'm just not sure if we should create such an additional package
automatically (sure),
and how to add --exclude=/usr/lib/debug easily to the existing pkg contents.
I'm sure Yaakov has a better idea than my ad-hoc approach I'm thinking of.

Treating the -dbg package as an ordinary split package has a few drawbacks:

*) 1:1 packages (IOW source packages which create one binary package of the same name) would all need to add PKG_NAMES and *_CONTENTS defines.

*) 1:x packages (IOW source packages which create several binary packages, e.g. libraries) would have to modify their existing PKG_NAMES and *_CONTENTS to add another package and not include the .dbg files in another package.

*) An additional setup.hint would have to be added for each package.

I'm not sure that cygport could flawlessly automate any or all of the above.

An alternative is to create a new type of package tarball. We currently have:

* Binaries (Bin in setup.exe, install: in setup.ini)
* Sources (Src in setup.exe, source: in setup.ini)

What about adding a third type:

* Debug (Dbg in setup.exe, debuginfo: in setup.ini)

cygport could then strip the symbols into a location _outside_ of ${D}, (thereby avoiding the issues mentioned above) and create a ${PN}-${PV}-${PR}-dbg.tar.bz2 package from that. upset could then use the same rules it uses for source: to add a debuginfo: for each @Package. (IOW there would be only one -dbg per -src, no matter how many binary packages were created.) Then a user would just X the Dbg column in setup.exe for their package they want to debug.

This would require changes in cygport, upset, and setup.exe but would save maintainers from having to change each one of their packages.


__prepdebug() {
	if defined _CYGPORT_RESTRICT_debug_
		inform "Skipping -debuginfo package per request.";
		return 0;

Yes, this option will be needed in some cases.

                         s=$(basename ${exe} .exe)
                         s=$(basename ${s} .dll)


There are now four supported extensions (.exe, .dll, .so, .cmxs), and we use bashisms in cygport as much as possible to avoid fork&exec's.

                         objcopy --only-keep-debug ${exe}
                         objcopy --strip-debug ${exe}
--add-gnu-debuglink=${debugdir}/${d}/${s}.dbg ${exe}


-- Problem reports: FAQ: Documentation: Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]