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

On 18/02/2012 11:47 AM, Jon TURNEY wrote:
On 21/08/2009 00:40, Yaakov (Cygwin/X) wrote:
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.
FWIW, attached is the patch I've been using to do this, based on Reini's
patch, updated to address some of your concerns.

This can, as you suggested, strip the symbols to a location outside of ${D}
and create a single debuginfo package containing those symbols for each cygport.

I know that support for these packages in upset and setup has been rejected by
cgf, but it's still useful to me to keep the debuginfo for the packaged builds
of Xwin around.

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?)
The debug info can correctly reflect optimizations that have taken place (e.g.
variables that have been optimized out or source lines that have been become

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?
AFAIK, -fomit-frame-pointer doesn't break recent versions gdb, because gcc stores directions in the debug info on how to find the return address and other frame information from any PC. You're SOL with stripped binaries, tho. This is useful not only for missing frame pointers but also function during prologues/epilogues (when the frame isn't set up properly), frames that alloca() has messed up, and (bonus) for missing frames that arise because the function got inlined (gdb can still tell you which line(s) of which inlined function(s) a given instruction corresponds to.

The one caveat is that the gcc devs decided it's less confusing to debug optimized code if functions appear to remain "well-nested" -- inlined code is no longer "seen" to bleed into the surrounding caller. THIS DOES NOT AFFECT OPTIMIZATION -- instructions continue to bleed like crazy under the hood, but gcc assigns arbitrary boundaries for deciding whether code is "inside" or "outside" the inlined function. You can even set breakpoints in inlined functions, as long as it didn't get optimized away completely. The only real downside is that it reduces the accuracy of sample-based profiling (you can "blame" the wrong function); but I have to admit it is disorienting to jump repeatedly between "caller" and "callee" when there's been inlining.

My $.02 is that it would be very nice to have .dbg available for those who need it. For recent woes with slow file operations I downloaded cygwin1.dll myself just to have the corresponding .dbg, but for any actual apps you end up compiling the code yourself.


-- 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]