looking for a program

Gorman, John John.Gorman@pegs.com
Wed, 7 Feb 2001 08:11:18 -0700


testing....

-----Original Message-----
From: Kevin Buettner [mailto:kev@primenet.com]
Sent: Wednesday, February 07, 2001 12:28 AM
To: plug-discuss@lists.PLUG.phoenix.az.us
Subject: Re: looking for a program


On Feb 6, 11:39pm, der.hans wrote:

> Since you're basically throwing it a line of code in a command line type
> of way it seems like you kind of have a shell for c/c++ and whatever else
> gdb understands. Is that somewhat correct?

gdb has its own command language.  Built into it are expression
evaluators for the languages it supports.  Note that I said
expressions and not statements...

> If so, can you toss it a few lines of code, specifically a loop or other
> control block to test it out. Sort of like a "for i in ..." construct from
> a shell command line?

...which means that you can't write ``for'' loops and such.

But, for debugging purposes, just being able to handle C/C++ expressions
(and expressions for the other supported languages too) is incredibly
useful.  E.g. if you know that you have an array of struct foo at location
0x1000, you can do the following to print out array elements.

    (gdb) print ((struct foo *) 0x1000)[4]

Also, expressions can be used with breakpoint commands.  E.g.
suppose you suspect a problem in function bar...

    void
    bar (int i, enum color moon)
    {
      ...
    }

...but you suspect that the problem only occurs when i is 42 and the
moon is blue.  You can tell gdb the following:

    (gdb) break bar if i == 42 && moon == blue

(gdb learns a lot about the types used in your program by reading
the debugging information.)

> Can you include files, then run stuff?

You can use gdb's command language to define your own commands and
there is a facility for loading/running gdb commands.  This is most
commonly done via a file called .gdbinit which is read when gdb is
started.  But you can also put gdb commands into any arbitrary file.
This facility is really handy when you have a (tedious) recipe for
getting to the location where your bug is and you need to rerun the
debugger more than once to narrow the problem down.

> I'm starting to look at c stuff again ( that's what I'm planning for my
> spare nano-second this year ;-), so if I could do some of those stupid
> shell tricks from a c 'command line' I could practice doing them in c :).

I see where you're coming from.  I don't think gdb will serve your
purposes.  There are some C interpreters out there though.  But I
forgot what they're called.

But back to gdb.  It's an incredibly powerful tool.  If you're doing
C/C++ programming on Linux (or any other *nix), it is definitely
worth your time to learn it.  For those of you out there who can't
live without a GUI, try out either insight (available from
sources.redhat.com) or DDD.  DDD is available from

    http://www.cs.tu-bs.de/softech/ddd/ddd.html

DDD is a graphical front end to gdb and other debuggers.  The
"insight" debugger has a tighter integration with gdb.

Kevin

________________________________________________
See http://PLUG.phoenix.az.us/navigator-mail.shtml if your mail doesn't post
to the list quickly and you use Netscape to write mail.

Plug-discuss mailing list  -  Plug-discuss@lists.PLUG.phoenix.az.us
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss