From: Steve Graegert <graegerts@gmail.com>
To: linux-c-programming@vger.kernel.org
Subject: Re: Debugging
Date: Sun, 29 Jan 2006 17:21:38 +0100 [thread overview]
Message-ID: <6a00c8d50601290821q38b1b38esc773ccf1125c3c1f@mail.gmail.com> (raw)
In-Reply-To: <43DC5EFA.7010001@colannino.org>
On 1/29/06, James Colannino <james@colannino.org> wrote:
> Hey everyone. I have a small program that I had written a while ago in
> C to help me study for my Spanish class. I decided to rewrite some code
> recently being that I have a little more experience, and found that the
> program does not function properly when I compile with -O2 optimizations
> (I'm using GCC.) It works as it should, however, when there are no
> optimizations. How exactly should I go about debugging this and
> figuring out what code is causing the problem? I could compile it with
> the -g option and feed it to GDB, but then doesn't debugging not work
> very well when you've done optimizations? Is -O2 a low enough level of
> optimization that I shouldn't have a problem? Debugging is one of the
> many things I know extremely little about, so I'm very in the dark
> here. Any input would be greatly appreciated :) Thanks very much in
> advance.
James,
debugging optimized code is very difficult for the following reasons
(to name a few):
- due to a technique known as "common subexpression elimination"
you may not be able to stop on certain statements, although you think
it should be possible.,
- instruction scheduling causes statements (typically those
resulting in load/store operations as found in computations of values)
to be moved around, i.e. move them close to the location where they
are used,
- sometimes similar code fragments are merged so that the program
counter jumps to unexpected locations (often seen with return or break
statements).
There are other anomalies you may encounter when debugging optimized
code and I therefore recommend to increase the level of optimization
step by step beginning with -O0 and then to debug at each level to
check for unexpected values of variables and other bogus behavior. I
am sure the GCC/gdb manual will reveal some helpful information about
debugging.
\Steve
--
Steve Graegert <graegerts@gmail.com>
Software Consultant {C/C++ && Java && .NET}
Office: +49 9131 7123988
Mobile: +49 1520 9289212
next prev parent reply other threads:[~2006-01-29 16:21 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-29 6:21 Debugging James Colannino
2006-01-29 16:21 ` Steve Graegert [this message]
2006-01-29 18:14 ` Debugging Glynn Clements
2006-01-30 19:09 ` Debugging James Colannino
[not found] ` <20060129105131.6813f695.leslie.polzer@gmx.net>
2006-01-30 19:13 ` Debugging James Colannino
2006-01-30 19:21 ` Debugging James Colannino
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6a00c8d50601290821q38b1b38esc773ccf1125c3c1f@mail.gmail.com \
--to=graegerts@gmail.com \
--cc=linux-c-programming@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).