help me reduce typing when running gdb

Hi, I often perform these steps:

1. bjam
2. gdb ./bin/debug/prog
3. r very long list of parameters that I hate typing
4. [lots of debugger commands like c, n, s, break, etc]
5. up arrow many times to get back to the run command
w/parms
6. q
7. vi source.cpp
8. goto 1

Can anyone recommend a way to streamline this process? 
Particularly 
Step 3 and Step 5.  In MSVC, steps 1-3 is one keystroke (F5)
and step 5 
is two (SHIFT-F5, F5).

Thanks for your help in switching over to gdb!

Chris

> Hi, I often perform these steps:
>
> 1. bjam
> 2. gdb ./bin/debug/prog
> 3. r very long list of parameters that I hate typing
> 4. [lots of debugger commands like c, n, s, break,
etc]
> 5. up arrow many times to get back to the run command
w/parms
> 6. q
> 7. vi source.cpp
> 8. goto 1
>
> Can anyone recommend a way to streamline this process? 
Particularly
> Step 3 and Step 5.  In MSVC, steps 1-3 is one keystroke
(F5) and step 5
> is two (SHIFT-F5, F5).

Well in gdb you could put this in a command file and then
source it . Look
at the source command . Or you could put it all of them in
.gdbinit file
in your home directory.

You can also define your own custom commands - so run with
params can be a
command that you define using define command.

Also after the first run with params , the second run always
by default
takes the params you specified in the first call to run .

 So r < huge list of params>
  ...
....
... ( do lots of debug)

r

has the same effect as replacing the r with r <huge list
of params>

HTH

cheers
Ramana




cheers
Ramana

>
> Thanks for your help in switching over to gdb!
>
> Chris
>

On Wed, 2007-11-28 at 11:43 -0800, Chris Stankevitz wrote:
> Hi, I often perform these steps:
> 
> 1. bjam
> 2. gdb ./bin/debug/prog
> 3. r very long list of parameters that I hate typing
> 4. [lots of debugger commands like c, n, s, break,
etc]
> 5. up arrow many times to get back to the run command
w/parms
> 6. q
> 7. vi source.cpp
> 8. goto 1
> 
> Can anyone recommend a way to streamline this process? 
Particularly 
> Step 3 and Step 5.  

Sure.

1. cat > .gdbinit
   define myrun
     run <very long list of parameters that I hate
typing>
   end
   ^D
2. gdb ./bin/debug/prog
3. myrun
4. [lots of debugger commands like c, n, s, break, etc]
5. myrun

Chris Stankevitz wrote:
> Hi, I often perform these steps:
>
> 1. bjam
> 2. gdb ./bin/debug/prog
> 3. r very long list of parameters that I hate typing
> 4. [lots of debugger commands like c, n, s, break,
etc]
> 5. up arrow many times to get back to the run command
w/parms
> 6. q
> 7. vi source.cpp
> 8. goto 1
>
> Can anyone recommend a way to streamline this process? 
Particularly 
> Step 3 and Step 5.  In MSVC, steps 1-3 is one keystroke
(F5) and step 
> 5 is two (SHIFT-F5, F5).

Most IDEs which use gdb provide similar features. Try
NetBeans with 
C/C++ support
or Eclipse with CDT (I recommend NetBeans as I'm the gdb
module developer

Gordon

>
> Thanks for your help in switching over to gdb!
>
> Chris

Chris Stankevitz wrote:
> Can anyone recommend a way to streamline this process?

Thanks for the helpful responses, everyone.  I set up custom
routines in 
my .gdbinit file.  I'll also take advantage of gdb
remembering parms 
when retyping commands.

MSVC has been a part of my life for 6 years -- I'm fluent
and quick in 
it and I want to get the same with gdb, but right now I feel
so ... 
restricted.  I'll take a look at NetBeans too.

Thanks,

Chris

Chris Stankevitz <cstankevitztoyon.com> writes:

> Hi, I often perform these steps:
>
> 1. bjam
> 2. gdb ./bin/debug/prog
> 3. r very long list of parameters that I hate typing
> 4. [lots of debugger commands like c, n, s, break,
etc]

5. edit
6. make
7. run
8. goto 4

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwabsuse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg,
Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5
214B 8276 4ED5
"And now for something completely different."

>>>>> "Chris" == Chris Stankevitz
<cstankevitztoyon.com> writes:

In addition to what everybody else said...

Chris> 2. gdb ./bin/debug/prog
Chris> 3. r very long list of parameters that I hate
typing

Here I frequently use:

gdb --args ./bin/debug/prog lots of parameters

This works nicely unless you have to redirect input or
output.

Chris> 6. q

Don't quit.  Edit your source, rebuild, and then in gdb just
'r'.
It will reuse the arguments and will re-read the updated
executable.

This isn't always foolproof.  For instance, if your OS has
address
space randomization, and you have a watchpoint installed,
you will
have to delete the watchpoint.  (If you're doing a lot of
difficult
debugging, find out how to disable randomization.)

If you are an Emacs user, run gdb in Emacs.

Tom

Chris Stankevitz wrote:
> Can anyone recommend a way to streamline this process? 
Particularly 
> Step 3 and Step 5.  In MSVC, steps 1-3 is one keystroke
(F5) and step 5 
> is two (SHIFT-F5, F5).

The TUI has some single key commands for stepping and such -
I use those 
a lot. The source view is very nice to have too.

You might also like to check out the history save feature. I
have these 
lines in my .gdbinit:

   set history expansion
   set history save on

Basically it just means that, when you start a new GDB
session in the 
same directory as a previous one, you can hit 'up' and the
commands from 
your last session are still there.

Andrew