gcc compiler - debuging
t
How to debuge programc in gcc
Ramon
> Hi
> How to debuge programc in gcc
>
Use gdb -- GNU Debugger
Maxim Yegorushkin
> Hi
> How to debuge programc in gcc
You need to use a debugger, such as gdb. Google for "gdb tutorial".
Another option is to use some integrated development environment, such
as free ones Eclipse or NetBeans. They may be much easier to start with
for beginners.
--
Max
Jorgen Grahn
> On 25/10/09 14:51, t wrote:
>> Hi
>> How to debuge programc in gcc
>
> You need to use a debugger, such as gdb. Google for "gdb tutorial".
Well, he doesn't actually need a debugger to debug.
Debugging is to me the activity of fixing bugs in general. You can do
that by reading the code, inserting printf()s, writing unit tests,
running it under strace/valgrind/etc, provoking it in various ways ...
or stepping around in a symbolic debugger.
Personally I never learned to enjoy that last kind of debugging, not
even in C with its usually simpler call chains. (Although naturally I
use gdb for post-mortem debugging of core dumps -- I'm not stupid).
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
jacob navia
You never learned to use a debugger?
If you would have learned, then you would need to do post
mortem debugging less often...
:-)
Maybe you can call it "pre-mortem" :-)
Maxim Yegorushkin
> On Sun, 2009-10-25, Maxim Yegorushkin wrote:
>> On 25/10/09 14:51, t wrote:
>>> Hi
>>> How to debuge programc in gcc
>>
>> You need to use a debugger, such as gdb. Google for "gdb tutorial".
>
> Well, he doesn't actually need a debugger to debug.
>
> Debugging is to me the activity of fixing bugs in general. You can do
> that by reading the code, inserting printf()s, writing unit tests,
> running it under strace/valgrind/etc, provoking it in various ways ...
> or stepping around in a symbolic debugger.
Can not agree more.
> Personally I never learned to enjoy that last kind of debugging, not
> even in C with its usually simpler call chains. (Although naturally I
> use gdb for post-mortem debugging of core dumps -- I'm not stupid).
My first computer was a russian clone of Z80. Most of Z80 programs were
naturally written in assembly language, so the first thing to learn was
to inspect Z80 assembly code with a debugger and a pencil to comment,
injecting printf() statements was science fiction for me at the time ;)
--
Max
Juha Nieminen
> Debugging is to me the activity of fixing bugs in general. You can do
> that by reading the code, inserting printf()s, writing unit tests,
> running it under strace/valgrind/etc, provoking it in various ways ...
> or stepping around in a symbolic debugger.
You forgot the liberal use of assert(). I cannot even count how many
bugs I have caught very early on development thanks to my liberal use of
assert().
Jorgen Grahn
Yeah -- including that one I half-jokingly wanted to have in the
standard library: assume(), hope() or jump_to_conclusion().
(For when you want to assert() something in early prototyping, but
know that you *will* have to handle it seriously later on.)
James Kanze
> Jorgen Grahn a écrit :
More likely, you're confusing cause and effect. He's never
learned to use a debugger because he hasn't needed it: some of
the ways he has enumerated (code review, detailed unit tests)
are more effective than a debugger in finding an eliminating
bugs. I know that in situations where good code review and
extensive unit tests are required, almost no one ends up using
the debugger, and in general, I feel that if I need a debugger,
I'm doing something wrong: programming too carelessly, for
example, or not writing detailed enough unit tests. (Typically,
I'll use one once or twice a year, at the most, and I've done
whole projects without one.)
--
James Kanze
Jorgen Grahn
> Jorgen Grahn a �crit :
>> On Sun, 2009-10-25, Maxim Yegorushkin wrote:
>>> On 25/10/09 14:51, t wrote:
>>>> Hi
>>>> How to debuge programc in gcc
>>> You need to use a debugger, such as gdb. Google for "gdb tutorial".
>>
>> Well, he doesn't actually need a debugger to debug.
>>
>> Debugging is to me the activity of fixing bugs in general. You can do
>> that by reading the code, inserting printf()s, writing unit tests,
>> running it under strace/valgrind/etc, provoking it in various ways ...
>> or stepping around in a symbolic debugger.
>>
>> Personally I never learned to enjoy that last kind of debugging, not
>> even in C with its usually simpler call chains. (Although naturally I
>> use gdb for post-mortem debugging of core dumps -- I'm not stupid).
>
> You never learned to use a debugger?
I never learned to *enjoy* it, that was what I wrote. But yes, I tend
to get lost quickly, and I make frequent mistakes, like setting
breakpoints in the wrong place.
I don't think this is embarrassing or unusual. Most programmers I
know don't use debuggers that way. Maybe it's more common among
Windows programmers -- I have seen one or two good ones use it a lot.
> If you would have learned, then you would need to do post
> mortem debugging less often...
>
> :-)
I doubt that. I haven't seen people step around in a debugger and
discover crashes they couldn't find more easily by just running the
program (possibly under valgrind or a similar tool).
Juha Nieminen
> Yeah -- including that one I half-jokingly wanted to have in the
> standard library: assume(), hope() or jump_to_conclusion().
Actually an "assume()" function/keyword could be useful in that it
could help the compiler to perform better optimizations. For example,
you could have something like this:
void foo(double d)
{
assume(d >= 0.0);
double sd = std::sqrt(d);
....
}
If NDEBUG is not defined, the assume() would work as a regular
assert(). In either case the compiler could use it to optimize the
subsequent std::sqrt call because it can assume that d is always
non-negative.
Jorgen Grahn
Hm, maybe -- but then you have a different definition than I had:
(For when you want to assert() something in early prototyping, but
know that you *will* have to handle it seriously later on.)
It's not a hint to the compiler about what will be the usual case,
it's a hint to the reader that the code isn't yet solid.
In your foo(double) example, I would have simply used assert(d >= 0.0).