

use infinite loop to show how to attach to a running program

1) two windows
./infiniteloop foo
 
in another window

ps -elf | grep infiniteloop | grep jnm

ps -efl |head -2  to see which is process id

note process id

2) 
gdb infiniteloop <process id>

(Note first tries to look for core file named <process id>)

If there process executes exactly the same program whose path we gave to gdb (not a copy of the file. it must be the exact same file that the process runs), it'll attach to the program, pause its execution, and will let us continue debugging it as if we started the program from inside the debugger. Doing a "where" right when we get gdb's prompt will show us the stack trace of the process, and we can continue from there. Once we exit the debugger, It will detach itself from the process, and the process will continue execution from where we left it. 

3) 
will stop execution

where

do  "finish" till get to main for loop
periodically do where

finish = Keeps doing nexts, without stepping, until reaching the end of the current function


4)
then do n a while

note how program continues 

5) 
set break point
break


6)
detach

7)
attach <process>id>

continue

note break point is still set


8)
print j=numPrint+1

c
will exit normally

OR

-------------------------------------------------

1) run infinite loop again

2) attach <new process id>

3) list infiniteloop.c:main

4) list again until see line number
	of call to print_string

5) break infiniteloop.c:35
   c

6) note i num in output window
info break

7) commands 1
print i
end

8) display numPrint
n
n
n

Note numPrint always displayed
i only displayed with breakpoint 1

8)info display
undisplay 1


9) info break
   ignore 1 10 
   c

10) condition 1 i>4000
    c

11)


(gdb) info frame 
Stack level 0, frame at 0xeffff850:
 pc = 0x1077c in main (infiniteloop.c:35); saved pc 0x10540
 source language c.
 Arglist at 0xeffff850, args: argc=3, argv=0xeffff8b4
 Locals at 0xeffff850,
(gdb) disas 0x1077c 0x10780
Dump of assembler code from 0x1077c to 0x10780:
0x1077c <main+220>:     mov  4, %o0     ! 0x4
End of assembler dump.
(gdb) disas 0x1077c 0x10788
Dump of assembler code from 0x1077c to 0x10788:
0x1077c <main+220>:     mov  4, %o0     ! 0x4
0x10780 <main+224>:     ld  [ %fp + 0x48 ], %o2
0x10784 <main+228>:     add  %o0, %o2, %o1
End of assembler dump.


12) info registers

13) 
(gdb) call print_string(10, "foobar")
String '10' - 'foobar'

13) list 
note a line just passed the end of the loop

14)

jump infiniteloop.c:38 
------------------------------------------------

gdb infiniteloop
break main
run foo 6
print numPrint
watch numPrint
c

Hardware watchpoint 2: numPrint
 
Old value = 0
New value = 6
main (argc=3, argv=0xeffff8b4) at infiniteloop.c:25
25          if ((numPrint ==0) && (errno = EINVAL)){


______________________________________________
other tricks

shell echo foo

shell date

shell hostname

make clean

make

file infiniteloop  (notice tab completion)

break points still there ??? could they be screwed up?



return 5  (make main return 5)

can also from within any function make it
return a value
_____________________________________
emacs
M-x gdb
gdb infiniteloop

break main

run

n
n
n
________________________________________

ps -efl

get processId

kill -11 <processId>

core file you can use gdb to examine
rather than stop the process

_____________________________________
use linked list to show graphical ddd

_______________________________________________________________
http://www.gnu.org/manual/manual.html
http://www.gnu.org/doc/gdb-manual.html
http://www.cs.princeton.edu/~benjasik/gdb/gdbtut.html
__________________________________________
Forcing a Core Dump 

While frequently core dumps happen when least desired, it is possible to force Unix to terminate the process's execution and write it to a core file. To force a foreground process to core dump hold down the control key and press the \ key. 

If the process is a background process it can either be brought to the foreground and killed using the procedure mentioned or killed with signal 11 (ie kill -11 processid). 

_____________________________

GDB under Emacs 
Emacs provides a much better interface to gdb that saves a lot of typing and confusion. Executing the Emacs command M-x gdb starts up a new window running gdb. If you set a breakpoint on the main function and then run the program with the correct arguments, gdb will split the window in two, with your source code on the bottom and a gdb command line in the top. Emacs intercepts output from gdb and interprets it for you. When you stop at a breakpoint, Emacs will take the file and line number reported by gdb, and display the file contents, with the point of the breakpoint market. As you step through a program, Emacs will follow your pgoress in the source file. The command C-x SPC will place a breakpoint at the current point of the file you are in.


_______________________________________________________________

http://www.informatik.hu-berlin.de/~mueller/TDI/

A Thread Debug Interface (TDI)
for Implementations of
the POSIX Threads (Pthreads) Standard

=========

Debugging programs with multiple threads
In some operating systems, a single program may have more than one thread of execution. The precise semantics of threads differ from one operating system to another, but in general the threads of a single program are akin to multiple processes--except that they share one address space (that is, they can all examine and modify the same variables). On the other hand, each thread has its own registers and execution stack, and perhaps private memory. 

GDB provides these facilities for debugging multi-thread programs: 

automatic notification of new threads 
`thread threadno', a command to switch among threads 
`info threads', a command to inquire about existing threads 
`thread apply [threadno] [all] args', a command to apply a command to a list of threads 
thread-specific breakpoints 
Warning: These facilities are not yet available on every GDB configuration where the operating system supports threads. If your GDB does not support threads, these commands have no effect. For example, a system without thread support shows no output from `info threads', and always rejects the thread command, like this: 

(gdb) info threads
(gdb) thread 1
Thread ID 1 not known.  Use the "info threads" command to
see the IDs of currently known threads.

________________________________________

Kernel Debugging

http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html

_______


TotalView debugger

_________________________________________________________________



shell command string 
Invoke a the standard shell to execute command string. If it exists, the environment variable SHELL determines which shell to run. Otherwise GDB uses /bin/sh. 
The utility make is often needed in development environments. You do not have to use the shell command for this purpose in GDB: 

make make-args 
Execute the make program with the specified arguments. This is equivalent to `shell make make-args'. 


____________________________


Setting watchpoints

You can use a watchpoint to stop execution whenever the value of an expression changes, without having to predict a particular place where this may happen. 

Watchpoints currently execute two orders of magnitude more slowly than other breakpoints, but this can be well worth it to catch errors where you have no clue what part of your program is the culprit. 

watch expr 
Set a watchpoint for an expression. GDB will break when expr is written into by the program and its value changes. This can be used with the new trap-generation provided by SPARClite DSU. DSU will generate traps when a program accesses some date or instruction address that is assigned to the debug registers. For the data addresses, DSU facilitates the watch command. However the hardware breakpoint registers can only take two data watchpoints, and both watchpoints must be the same kind. For example, you can set two watchpoints with watch commands, two with rwatch commands, or two with awatch commands, but you cannot set one watchpoint with one command and the other with a different command. will reject the command if you try to mix watchpoints. Delete or disable unused watchpoint commands before setting new ones. 
rwatch expr 
Set a watchpoint that will break when watch args is read by the program. If you use both watchpoints, both must be set with the rwatch command. 
awatch expr 
Set a watchpoint that will break when args is read and written into by the program. If you use both watchpoints, both must be set with the awatch command. 
info watchpoints 
This command prints a list of watchpoints and breakpoints; it is the same as info break. 
Warning: in multi-thread programs, watchpoints have only limited usefulness. With the current watchpoint implementation, GDB can only watch the value of an expression in a single thread. If you are confident that the expression can only change due to the current thread's activity (and if you are also confident that no other thread can become current), then you can use watchpoints as usual. However, GDB may not notice when a non-current thread's activity changes the expression. 

____-____-____-____-____-____-____-____-____-


condition bnum expression 
Specify expression as the break condition for breakpoint or watchpoint number bnum. After you set a condition, breakpoint bnum stops your program only if the value of expression is true (nonzero, in C). When you use condition, GDB checks expression immediately for syntactic correctness, and to determine whether symbols in it have referents in the context of your breakpoint. GDB does not actually evaluate expression at the time the condition command is given, however. See section Expressions. 

____________________________________________________

You can give any breakpoint (or watchpoint) a series of commands to execute when your program stops due to that breakpoint. For example, you might want to print the values of certain expressions, or enable other breakpoints. 

commands [bnum] 
... command-list ... 
end 
Specify a list of commands for breakpoint number bnum. The commands themselves appear on the following lines. Type a line containing just end to terminate the commands. To remove all commands from a breakpoint, type commands and follow it immediately with end; that is, give no commands. With no bnum argument, commands refers to the last breakpoint or watchpoint set (not to the breakpoint most recently encountered). 
______________________________________________________________


u 
until 
Continue running until a source line past the current line, in the current stack frame, is reached. This command is used to avoid single stepping through a loop more than once. It is like the next command, except that when until encounters a jump, it automatically continues execution until the program counter is greater than the address of the jump. This means that when you reach the end of a loop after single stepping though it, until makes your program continue execution until it exits the loop. In contrast, a next command at the end of a loop simply steps back to the beginning of the loop, which forces you to step through the next iteration. until always stops your program if it attempts to exit the current stack frame. until may produce somewhat counterintuitive results if the order of machine code does not match the order of the source lines. For example, in the following excerpt from a debugging session, the f (frame) command shows that execution is stopped at line 206; yet when we use until, we get to line 195: 


_____________________________________________________


until location

_______________________________________________________

info frame

This command prints a verbose description of the selected stack frame, including: 
the address of the frame 
the address of the next frame down (called by this frame) 
the address of the next frame up (caller of this frame) 
the language in which the source code corresponding to this frame is written 
the address of the frame's arguments 
the program counter saved in it (the address of execution in the caller frame) 
which registers were saved in the frame 
The verbose description is useful when something has gone wrong that has made the stack format fail to fit the usual conventions. 


___________________________________________________________________________

list command

_______________________________________________________________________

disassemble 
This specialized command dumps a range of memory as machine instructions. The default memory range is the function surrounding the program counter of the selected frame. A single argument to this command is a program counter value; GDB dumps the function surrounding this value. Two arguments specify a range of addresses (first inclusive, second exclusive) to dump. 
We can use disassemble to inspect the object code range shown in the last info line example (the example shows SPARC machine instructions): 

(gdb) disas 0x63e4 0x6404
Dump of assembler code from 0x63e4 to 0x6404:
0x63e4 <builtin_init+5340>:     ble 0x63f8 <builtin_init+5360>
0x63e8 <builtin_init+5344>:     sethi %hi(0x4c00), %o0
0x63ec <builtin_init+5348>:     ld [%i1+4], %o0
0x63f0 <builtin_init+5352>:     b 0x63fc <builtin_init+5364>
0x63f4 <builtin_init+5356>:     ld [%o0+4], %o0
0x63f8 <builtin_init+5360>:     or %o0, 0x1a4, %o0
0x63fc <builtin_init+5364>:     call 0x9288 <path_search>
0x6400 <builtin_init+5368>:     nop
End of assembler dump.

___________________________yy___________________________

print exp 
print /f exp 
exp is an expression (in the source language). By default the value of exp is printed in a format appropriate to its data type; you can choose a different format by specifying `/f', where f is a letter specifying the format; see section Output formats. 


print file::variable
function::variable

gdb) p 'f2.c'::x

int *array = (int *) malloc (len * sizeof (int));

you can print the contents of array with 

p *array@len

____________________________________________

For example, to print the program counter in hex (see section Registers), type 

p/x $pc

_______________________________________________

_________________________________________________-_________________________________________________-y_________________________________________________-y


info registers

____________________________________________________________

altering execution

Once you think you have found an error in your program, you might want to find out for certain whether correcting the apparent error would lead to correct results in the rest of the run. You can find the answer by experiment, using the GDB features for altering execution of the program. 

For example, you can store new values into variables or memory locations, give your program a signal, restart it at a different address, or even return prematurely from a function. 

Assignment to variables
To alter the value of a variable, evaluate an assignment expression. See section Expressions. For example, 

set var x=4
print x=4


To store values into arbitrary places in memory, use the `{...}' construct to generate a value of specified type at a specified address (see section Expressions). For example, {int}0x83040 refers to memory location 0x83040 as an integer (which implies a certain size and representation in memory), and 

set {int}0x83040 = 4

stores the value 4 into that memory location. 

__________________________________________________

jump linespec 

return 
return expression 
You can cancel execution of a function call with the return command. If you give an expression argument, its value is used as the function's return value. 
When you use return, GDB discards the selected stack frame (and all frames within it). You can think of this as making the discarded frame return prematurely. If you wish to specify a value to be returned, give that value as the argument to return. 

Calling program functions

call expr 
Evaluate the expression expr without displaying void returned values. 






