From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: My Emacs unicode 2 crash again when I do some *Replace String (M-%)*, I give the debug informations under gdb in the attachments. Date: Fri, 09 Mar 2007 17:08:16 +0200 Message-ID: References: <20070306063056.GA21948@debian-testing-hy.localdomain> <86zm6q5upr.fsf@lola.quinscape.zz> <17902.9556.720278.162036@kahikatea.snap.net.nz> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: sea.gmane.org 1173452938 4002 80.91.229.12 (9 Mar 2007 15:08:58 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 9 Mar 2007 15:08:58 +0000 (UTC) Cc: emacs-devel@gnu.org To: Miles Bader Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 09 16:08:42 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HPght-00038c-1P for ged-emacs-devel@m.gmane.org; Fri, 09 Mar 2007 16:08:33 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HPgiA-00005S-Al for ged-emacs-devel@m.gmane.org; Fri, 09 Mar 2007 10:08:50 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HPghz-00005K-Oo for emacs-devel@gnu.org; Fri, 09 Mar 2007 10:08:39 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HPghx-000058-3z for emacs-devel@gnu.org; Fri, 09 Mar 2007 10:08:39 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HPghw-000055-VP for emacs-devel@gnu.org; Fri, 09 Mar 2007 10:08:36 -0500 Original-Received: from heller.inter.net.il ([213.8.233.23]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HPghV-0008Rn-5g for emacs-devel@gnu.org; Fri, 09 Mar 2007 10:08:09 -0500 Original-Received: from HOME-C4E4A596F7 (IGLD-80-230-36-31.inter.net.il [80.230.36.31]) by heller.inter.net.il (MOS 3.7.3a-GA) with ESMTP id CBW01672 (AUTH halo1); Fri, 9 Mar 2007 17:07:53 +0200 (IST) In-reply-to: (message from Miles Bader on Thu, 08 Mar 2007 13:50:42 +0900) X-detected-kernel: FreeBSD 4.7-5.2 (or MacOS X 10.2-10.4) (2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:67614 Archived-At: > From: Miles Bader > Date: Thu, 08 Mar 2007 13:50:42 +0900 > > Eli Zaretskii writes: > > If you use GCC, you are forced to debug and test with -O0, and then > > ship a program compiled with -O2 which you didn't debug and test. > > But that isn't true. It sometimes takes extra work to debug because of > optimization, but it's not some kind of impossible burden. I submit that it _is_ an all but impossible burden, since even the traceback shows many arguments passed to functions as "optimized out". How can you debug a program if you cannot see with what arguments were the offending functions called? And then there are functions that are inlined just because GCC thinks it's a good idea, which defeats your ability to put breakpoints (GDB will put a breakpoint where you asked it to, but the breakpoint will never break). Even without inlining, some code rearrangements also make it impossible or at least impractical to put breakpoints on source lines whose code happened to be rearranged. A typical (but not the only) example is that GCC folds several `return' statements into one opcode; putting a breakpoint on all but a single `return' out of all those that were folded runs a very high risk of not breaking. The only workaround is to disassemble and put breakpoints on addresses, not source lines. That is not my idea of source-level debugging. Stepping is unreliable with rearranged code, and it's very easy to miss that one step where the suspected code gets _really_ executed. Etc., etc. And this is with GCC and GDB, the two flagships of the GNU project, which I once used to be proud of using, and proud of showing off to users of other compilers. How sad. > > I couldn't convince GCC developers that debuggability is much more > > important in the vast majority of cases than the extra 5%-7% > > performance gains one gets by using all the tweaks -O2 does that > > defeat debugging. Sigh. > > Convince them to do what? To be user-friendlier to developers who want to debug optimized code. > They give you a bazillion knobs which you can use to tune the > tradeoffs made to your liking. That argument is invalid. First, there's no information in the GCC documentation that tells you which debug problems can be solved by what GCC switch. Moreover, some of the above ``features'' cannot be disabled individually, only by falling back on -O1 or -O0. I once suggested something like -Odebug, but since GCC developers are generally unsympathetic to the kind of gripes I presented, the suggestion was hardly noticed, and I don't hold my breath to see it implemented any time soon. Nor do I have any reason to hope that the GCC manual will be fixed to at least tell how to defeat the most wacky optimizations, in a way that would make this information easily comprehended by someone who is not a compiler expert, just a developer looking for ways to debug her program. > You can argue about the defaults, but -O2 _isn't the default_ The default is -O0, which is useless. Did you ever look at the horribly inefficient code produced by -O0? Anyway, -O2 _is_, in fact, a kind of default, since most (if not all) GNU packages use -O2 in their default builds.