Re: My Emacs unicode 2 crash again when I do some *Replace String (M-%)*, I give the debug informations under gdb in the attachments.

[Eli Zaretskii <eliz@gnu.org>]

> From: Miles Bader <miles.bader@necel.com>
> Date: Thu, 08 Mar 2007 13:50:42 +0900
> 
> Eli Zaretskii <eliz@gnu.org> 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.