Re: gcc compiler - debuging

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".

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

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.

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 .

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?

If you would have learned, then you would need to do post
mortem debugging less often...



Maybe you can call it "pre-mortem"

jacob navia

On 26/10/09 16:57, Jorgen Grahn wrote:
> 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

Maxim Yegorushkin

On Tue, 2009-10-27, Juha Nieminen wrote:
> Jorgen Grahn wrote:
>> 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().

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.)

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

Jorgen Grahn

On Oct 26, 5:56 pm, jacob navia <ja...@nospam.org> wrote:
> Jorgen Grahn a écrit :
> > On Sun, 2009-10-25, Maxim Yegorushkin wrote:
> >> On 25/10/09 14:51, t wrote:

> >>> 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?

> If you would have learned, then you would need to do post
> mortem debugging less often...

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

James Kanze

On Mon, 2009-10-26, jacob navia wrote:
> 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).

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

Jorgen Grahn

On Fri, 2009-10-30, Juha Nieminen wrote:
> Jorgen Grahn wrote:
>> 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.

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).

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

Jorgen Grahn