Message-ID: <4F3FEFE7.9050502@cs.utoronto.ca>
Date: Sat, 18 Feb 2012 13:37:27 -0500
From: Ryan Johnson <ryan.johnson@cs.utoronto.ca>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1
MIME-Version: 1.0
To: cygwin@cygwin.com
Subject: Re: add -debuginfo packages
References: <6910a60908041158p10fa632cvc2f21524e33b74ce@mail.gmail.com> <4A8DDEE8.2050606@users.sourceforge.net> <4F3FD634.7060503@dronecode.org.uk>
In-Reply-To: <4F3FD634.7060503@dronecode.org.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com

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