Request for hint on basic gdb use.

[Matt]

I'm working through this:

http://home.earthlink.net/~momotuk/pointers.pdf

On page 24:

"The reader should ... run .. code .. using a debugger .. while single
stepping".

I haven't used a debugger before. So far all I've achieved with gdb is
to have my code run exactly as if it were executed normally.

I've starting looking through this:

https://sourceware.org/gdb/download/onlinedocs/gdb/index.html

so I'll work it out soon enough but maybe someone can please provide a
brief hint in the meantime?

I'm not wedded to gdb. If you are familiar with something else please
provide a hint for that.

Thx, Matt.

 

[James Kuyper]

I'm working through this:

http://home.earthlink.net/~momotuk/pointers.pdf

On page 24:

"The reader should ... run .. code .. using a debugger .. while single
stepping".

I haven't used a debugger before. So far all I've achieved with gdb is
to have my code run exactly as if it were executed normally.

I've starting looking through this:

https://sourceware.org/gdb/download/onlinedocs/gdb/index.html

so I'll work it out soon enough but maybe someone can please provide a
brief hint in the meantime?

I'm not wedded to gdb. If you are familiar with something else please
provide a hint for that.

gdb would be pretty much useless if you couldn't make it stop somewhere
during the execution of your program. There are many ways to make this
happen, but as a beginner the most important one you need to know is the
'break' command. You can give it the name of a function, which causes it
to stop at the first line of that function. Later on, while the program
is stopped in a function, you can give break a line number, and it will
stop execution at that line in the current source code file. You can
also tell it to break at a specified line number in a specified file,
but I normally don't bother with that one.

To start the code running after setting a break point, type 'run'. If
the program takes command line arguments, type them after the word
"run". Later on, when it is stopped in a function, type "continue" or
just "c" if you want it to continue running at the point where it stopped.

To single step through the code, use the "next" command, or simply "n".

None of this would be useful if you couldn't collection information.
Again, there's many ways to do so, but the most important one for a
beginner is the 'print' command. Follow it by a C expression, and it
will print the value of that expression.

There's a lot more to learn, but those should be enough to get started.

 

[Johann Klammer]

gdb would be pretty much useless if you couldn't make it stop somewhere
during the execution of your program. There are many ways to make this
happen, but as a beginner the most important one you need to know is the
'break' command. You can give it the name of a function, which causes it
to stop at the first line of that function. Later on, while the program
is stopped in a function, you can give break a line number, and it will
stop execution at that line in the current source code file. You can
also tell it to break at a specified line number in a specified file,
but I normally don't bother with that one.

To start the code running after setting a break point, type 'run'. If
the program takes command line arguments, type them after the word
"run". Later on, when it is stopped in a function, type "continue" or
just "c" if you want it to continue running at the point where it stopped.

To single step through the code, use the "next" command, or simply "n".

None of this would be useful if you couldn't collection information.
Again, there's many ways to do so, but the most important one for a
beginner is the 'print' command. Follow it by a C expression, and it
will print the value of that expression.

There's a lot more to learn, but those should be enough to get started.

Also there's built-in help(type 'help')
and an info manual 'info gdb'.
backtrace and disassemble are rather useful.
Also, 'print' is /extremely/ useful and can be used to change program
state/call functions etc..
If you need to stop a program that's already running(you have attached
the gdb to a daemon etc..) ctrl-C seems to work(usually)

Make sure to compile with -g so you get debugging information.

Now you know everything

 

[glen herrmannsfeldt]

(snip)

gdb would be pretty much useless if you couldn't make it stop somewhere
during the execution of your program. There are many ways to make this
happen, but as a beginner the most important one you need to know is the
'break' command. You can give it the name of a function, which causes it
to stop at the first line of that function. Later on, while the program
is stopped in a function, you can give break a line number, and it will
stop execution at that line in the current source code file. You can
also tell it to break at a specified line number in a specified file,
but I normally don't bother with that one.

I suppose, but I used to use adb, and now reasonably often used gdb,
just to find out where my program was when it core dumped. Often enough,
that is enough to figure out what to fix.

-- glen

 

[Jorgen Grahn]

I'm working through this:

http://home.earthlink.net/~momotuk/pointers.pdf

On page 24:

"The reader should ... run .. code .. using a debugger .. while single
stepping".

Some of us find debuggers most useful for post mortem analysis, i.e.
to look at a core dump or similar and find the bug. That's an art
form in itself and involves commands like 'bt', 'print' and 'x'.

(/Running/ a program under a debugger is also an art form, but I
personally find it more difficult and less useful.)

/Jorgen

 

[Matt]

(/Running/ a program under a debugger is also an art form, but I
personally find it more difficult and less useful.)

The author of the pointers tutorial from my OP seems to think that by
single stepping through the examples a lightbulb will go off in my head
somehow. Now that I have done this (thx James, Johann for showing me
how) I have to say I didn't really find it that much of a revelation.
The material in the tutorial seems pretty clear on it's own.

Reading about the output formats for the gdb print command got me
thinking though - seems like there is a whole pandoras box there to do
with what things are and how they are represented. Sometimes I feel the
need to wilfully ignore complexity, at least until I have some other
requisite understanding to hang the new stuff on. If I had to
understand everything completely right away I'd go mad.

Thanks again clc'ers for generous advice.

Matt.

 

[James Kuyper]

The author of the pointers tutorial from my OP seems to think that by
single stepping through the examples a lightbulb will go off in my head
somehow.

The main thing a debugger is good for is to provide detailed information
about what your program is actually doing. If it's not doing what you
thought it would be doing, that can be helpful information. In
particular, it can be very helpful if you're sufficiently new to C that
you don't fully understand what it should be doing, which is why the
author of that tutorial recommended it. If no "lightbulbs went off"
while single stepping through the program, that implies that you
understood how it worked well enough to not be surprised by anything you
saw. That's a good thing, not a sign of any problems.

 

[Matt]

it can be very helpful if you're sufficiently new to C that
you don't fully understand what it should be doing, which is why the
author of that tutorial recommended it.

Agreed. Everyone comes to a given textbook or tutorial with their unique
background and experience. I would definitely recommend Ted Jensen's
pointers tutorial to any learner although 1 quibble from the pdf I
downloaded:

if(sizeof(long) != 4)
code on page 51 will not work properly

 

[wpihughes]

I'm working through this:



http://home.earthlink.net/~momotuk/pointers.pdf



On page 24:



"The reader should ... run .. code .. using a debugger .. while single

stepping".



I haven't used a debugger before. So far all I've achieved with gdb is

to have my code run exactly as if it were executed normally.



I've starting looking through this:



https://sourceware.org/gdb/download/onlinedocs/gdb/index.html



so I'll work it out soon enough but maybe someone can please provide a

brief hint in the meantime?



I'm not wedded to gdb. If you are familiar with something else please

provide a hint for that.



Thx, Matt.

I recommend the DDD front end to gdb (Unix only). It will help out
a lot with such things as setting breakpoints and looking at the values
of variables. Note that DDD will also work as a front end with many other
debuggers.

There is no DDD for Windows. I have used the MS debuggers with some success
(they have a similar look and feel) bu I have no done a great deal of debugging under windows. There are also DDD like programs than run
under windows. One I have heard mentioned is the Affinic Debugger GUI
(however, I have never used this.)

William Hughes