Mail Archives: cygwin/2012/02/18/13:37:56
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
> interleaved)
>
>> 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.
Ryan
--
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 -