Mail Archives: cygwin/2009/08/20/19:40:33
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.
Thoughts?
> __prepdebug() {
> if defined _CYGPORT_RESTRICT_debug_
> then
> inform "Skipping -debuginfo package per request.";
> return 0;
> fi
Yes, this option will be needed in some cases.
> s=$(basename ${exe} .exe)
> s=$(basename ${s} .dll)
s=${exe%.*}
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}
> ${D}${debugdir}/${d}/${s}.dbg
> objcopy --strip-debug ${exe}
> objcopy
> --add-gnu-debuglink=${debugdir}/${d}/${s}.dbg ${exe}
Yaakov
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -