Showing posts with label UNIX Tool's. Show all posts
Showing posts with label UNIX Tool's. Show all posts

Thursday, October 6, 2011

gdb tutorial


1. How do I use gdb?

When you compile your program, you must tell the compiler to produce a program that is compatible with the debugger. The debugger needs special information to run properly. To do this, you must compile your program with the debugger flag, -g. This step is critical. Without it, the debugger won't have the program symbol information. That means it won't know what your functions and variables are called, and it won't understand when you ask it about them.

1.1 How do I compile with debugging symbols?

Pass the -g flag to your compiler:
 
[sgupta@rhel6x64 socket]$ gcc -g program.c -o programname
 
NOTE: If you have a larger program with several files, each must be compiled with the -g flag, and it must also be set when you link.

1.2 How do I run programs with the debugger?

First start the debugger with your program name as the first argument.
 
[sgupta@rhel6x64 socket]$ gdb programname
 
Next use the run command in gdb to start execution. Pass your arguments to this command.
 
(gdb) run arg1 "arg2" ...

1.3 How do I restart a program running in the debugger?

Use the kill command in gdb to stop execution. The you can use the run command as shown above to start it again.
(gdb) kill
Kill the program being debugged? (y or n) y
(gdb) run ...

1.4 How do I exit the debugger?

Use the quit command.
(gdb) quit
NOTE: You may be asked if you want to kill the program. Answer yes.
(gdb) quit
The program is running. Exit anyway? (y or n) y
[sgupta@rhel6x64 socket]$

1.5 How do I get help on debugger commands?

Use the help command. Gdb has a description for every command it understand, and there are many, many more then this tutorial covers. The argument to help is the command you want information about. If you just type "help" with no arguments, you will get a list of help topics similar to the following: 

(gdb) help
List of classes of commands:

aliases -- Aliases of other commands
breakpoints -- Making program stop at certain points
data -- Examining data
files -- Specifying and examining files
internals -- Maintenance commands
obscure -- Obscure features
running -- Running the program
stack -- Examining the stack
status -- Status inquiries
support -- Support facilities
tracepoints -- Tracing of program execution without stopping the program
user-defined -- User-defined commands

Type "help" followed by a class name for a list of commands in that class.
Type "help" followed by command name for full documentation.
Command name abbreviations are allowed if unambiguous.


2. How do I watch the execution of my program?

Gdb functions somewhat like an interpreter for your programs. You can stop your program at any time by sending it signals. Normally this is done using key combinations like Ctrl-C for the interrupt signal SIGINT. Outside of gdb this would terminate your program. Gdb traps this signal and stops executing your program. Also, using breakpoints you can have your program stop executing at any line of code or function call. Once your program is stopped, you can examine 'where' it is in your code. You can look at the variables currently in scope, as well as your memory space and the cpu registers. You can also change variables and memory to see what effect it has on your code.

2.1 How do I stop execution?

You can stop execution by sending your program UNIX symbols like SIGINT. This is done using the Ctrl-C key combination. In the following example, I pressed Ctrl-C after 'Starting Program...' appeared.

(gdb) run
 
Starting Program: /home/ug/ryansc/a.out

Program received signal SIGINT, Interrupt.
0x80483b4 in main(argc=1, argv=0xbffffda4) at loop.c:5
5   while(1){
...
(gdb)

2.2 How do I continue execution?

Use the continue command to restart execution of your program whenever it is stopped.

2.3 How do I see where my program stopped?

Use the list command to have gdb print out the lines of code above and below the line the program is stopped at. In the example below, the breakpoint is on line 8.
 
(gdb) list
3       int main(int argc, char **argv)
4       {
5         int x = 30;
6         int y = 10;
7    
8         x = y;
9    
10        return 0;
11      }


2.4 How do I step through my code line-by-line?

First stop your program by sending it signals or using breakpoints. Then use the next and step commands.

5   while(1){
(gdb) next
7   }
(gdb)
 
NOTE: the next and step commands are different. On a line of code that has a function call, next will go 'over' the function call to the next line of code, while step will go 'into' the function call.
The next command:

(gdb)
11     fun1();
(gdb) next
12 }
The step command:
(gdb)
11     fun1();
(gdb) step;
fun1 () at loop.c:5
5    return 0;
(gdb)


2.5 How do I examine variables?

Use the print command with a variable name as the argument. For example, if you have int x and char *s:

(gdb) print x
$1 = 900
(gdb) print s
$3 = 0x8048470 "Hello World!\n"
(gdb)
 
NOTE: The output from the print command is always formatted $## = (value). The $## is simply a counter that keeps track of the variables you have examined.

2.6 How do I modify variables?

Use the set command with a C assignment statement as the argument. For example, to change int x to have the value 3:
 
(gdb) set x = 3
(gdb) print x
$4 = 3
 
NOTE: in newer versions of gdb, it may be necessary to use the command 'set var', as in 'set var x = 3'

2.7 How do I call functions linked into my program?

From the debugger command line you can use the call command to call any function linked into the program. This includes your own code as well as standard library functions. For example, if you wish to have your program dump core:

(gdb) call abort()

2.8 How do I return from a function?

Use the finish command to have a function finish executing and return to it's caller. This command also shows you what value the function returned.

(gdb) finish
Run till exit from #0  fun1 () at test.c:5
main (argc=1, argv=0xbffffaf4) at test.c:17
17        return 0;
Value returned is $1 = 1

3. How do I use the call stack?

The call stack is where we find the stack frames that control program flow. When a function is called, it creates a stack frame that tells the computer how to return control to its caller after it has finished executing. Stack frames are also where local variables and function arguments are 'stored'. We can look at these stack frames to determine how our program is running. Finding the list of stack frames below the current frame is called a backtrace.

3.1 How do I get a backtrace?

Use the gdb command backtrace. In the backtrace below, we can see that we are currently inside func2(), which was called bu func1(), which was called from main()

(gdb) backtrace
#0  func2 (x=30) at test.c:5
#1  0x80483e6 in func1 (a=30) at test.c:10
#2  0x8048414 in main (argc=1, argv=0xbffffaf4) at test.c:19
#3  0x40037f5c in __libc_start_main () from /lib/libc.so.6
(gdb)


3.2 How do I change stack frames?

Use the gdb command frame. Notice in the backtrace above that each frame has a number beside it. Pass the number of the frame you want as an argument to the command.
 
(gdb) frame 2
#2  0x8048414 in main (argc=1, argv=0xbffffaf4) at test.c:19
19        x = func1(x);
(gdb)


3.3 How do I examine stack frames?

To look at the contents of the current frame, there are 3 useful gdb commands. info frame displays information about the current stack frame. info locals displays the list of local variables and their values for the current stack frame, and info args displays the list of arguments.

(gdb) info frame
Stack level 2, frame at 0xbffffa8c:
eip = 0x8048414 in main (test.c:19); saved eip 0x40037f5c
called by frame at 0xbffffac8, caller of frame at 0xbffffa5c
source language c.
Arglist at 0xbffffa8c, args: argc=1, argv=0xbffffaf4
Locals at 0xbffffa8c, Previous frame's sp is 0x0
Saved registers:
 ebp at 0xbffffa8c, eip at 0xbffffa90
(gdb) info locals
x = 30
s = 0x8048484 "Hello World!\n"
(gdb) info args
argc = 1
argv = (char **) 0xbffffaf4

4. How do I use breakpoints?

Breakpoints are a way of telling gdb that you want it to stop your program at certain lines of code. You can also have it stop when your program makes specific function calls. Once the program is stopped, you can poke around in memory and see what the values of all your variables are, examine the stack, and step through your program's execution.

4.1 How do I set a breakpoint on a line?

The command to set a breakpoint is break. If you only have one source file, you can set a breakpoint like so:

(gdb) break 19
Breakpoint 1 at 0x80483f8: file test.c, line 19
If you have more than one file, you must give the break command a filename as well:
(gdb) break test.c:19
Breakpoint 2 at 0x80483f8: file test.c, line 19  

4.2 How do I set a breakpoint on a C function?
To set a breakpoint on a C function, pass it's name to break.
 
(gdb) break func1
Breakpoint 3 at 0x80483ca: file test.c, line 10    


4.3 How do I set a breakpoint on a C++ function?

Setting a breakpoint on a C++ function is similar to setting a breakpoint on a C function. However C++ is polymorphic, so you must tell break which version of the function you want to break on (even if there is only one). To do this, you tell it the list of argument types.
 
(gdb) break TestClass::testFunc(int)
Breakpoint 1 at 0x80485b2: file cpptest.cpp, line 16.


4.4 How do I set a temporary breakpoint?

Use the tbreak command instead of break. A temporary breakpoint only stops the program once, and is then removed.

4.5 How do I get a list of breakpoints?

Use the info breakpoints command.
 
(gdb) info breakpoints
Num Type           Disp Enb Address    What
2   breakpoint     keep y   0x080483c3 in func2 at test.c:5
3   breakpoint     keep y   0x080483da in func1 at test.c:10

4.6 How do I disable breakpoints?


Use the disable command. Pass the number of the breakpoint you wish to disable as an argument to this command. You can find the breakpoint number in the list of breakpoints, as shown above. In the example below we can see that breakpoint number 2 has been disabled (there is an 'n' under the Enb column).

(gdb) disable 2
(gdb) info breakpoints
Num Type           Disp Enb Address    What
2   breakpoint     keep n   0x080483c3 in func2 at test.c:5
3   breakpoint     keep y   0x080483da in func1 at test.c:10

4.7 How do I skip breakpoints?

To skip a breakpoint a certain number of times, we use the ignore command. The ignore command takes two arguments: the breakpoint number to skip, and the number of times to skip it. 

(gdb) ignore 2 5
Will ignore next 5 crossings of breakpoint 2.

5. How do I use watchpoints?

Watchpoints are similar to breakpoints. However, watchpoints are not set for functions or lines of code. Watchpoints are set on variables. When those variables are read or written, the watchpoint is triggered and program execution stops.
It is difficult to understand watchpoint commands by themselves, so the following simple example program will be used in the command usage examples.

#include <stdio.h>

int main(int argc, char **argv)
{
   int x = 30;
   int y = 10;

   x = y;

   return 0;
}

5.1 How do I set a write watchpoint for a variable?

Use the watch command. The argument to the watch command is an expression that is evaluated. This implies that the variabel you want to set a watchpoint on must be in the current scope. So, to set a watchpoint on a non-global variable, you must have set a breakpoint that will stop your program when the variable is in scope. You set the watchpoint after the program breaks.
 
NOTE: You may notice in the example below that the line of code printed doesn't match with the line that changes the variable x. This is because the store instruction that sets off the watchpoint is the last in the sequence necessary to do the 'x=y' assignment. So the debugger has already gone on to the next line of code. In the examples, a breakpoint has been set on the 'main' function and has been triggered to stop the program.

(gdb) watch x
Hardware watchpoint 4: x
(gdb) c
Continuing.
Hardware watchpoint 4: x

Old value = -1073743192
New value = 11
main (argc=1, argv=0xbffffaf4) at test.c:10
10      return 0;

5.2 How do I set a read watchpoint for a variable?

Use the rwatch command. Usage is identical to the watch command.
 
(gdb) rwatch y
Hardware read watchpoint 4: y
(gdb) continue
Continuing.
Hardware read watchpoint 4: y

Value = 1073792976
main (argc=1, argv=0xbffffaf4) at test.c:8
8         x = y;

5.3 How do I set a read/write watchpoint for a variable?

Use the awatch command. Usage is identical to the watch command.

5.4 How do I disable watchpoints?

Active watchpoints show up the breakpoint list. Use the info breakpoints command to get this list. Then use the disable command to turn off a watchpoint, just like disabling a breakpoint.

(gdb) info breakpoints
Num Type           Disp Enb Address    What
1   breakpoint     keep y   0x080483c6 in main at test.c:5
       breakpoint already hit 1 time
4   hw watchpoint  keep y   x
       breakpoint already hit 1 time

6. Advanced gdb Features

6.1 How do I examine memory?

Use the x command to examine memory. The syntax for the x command is x/FMT ADDRESS. The FMT field is a count followed by a format letter and a size letter. There are many options here, use the help command 'help x' to see them all. The ADDRESS argument can either be a symbol name, such as a variable, or a memory address.
If we have
char *s = "Hello World";
some uses of the x command could be:

Examine the variable as a string:
 
(gdb) x/s s
0x8048434 <_IO_stdin_used+4>:    "Hello World\n"
Examine the variable as a character:
(gdb) x/c s
0x8048434 <_IO_stdin_used+4>:   72 'H'
Examine the variable as 4 characters:
(gdb) x/4c s
0x8048434 <_IO_stdin_used+4>:   72 'H'  101 'e' 108 'l' 108 'l'
Examine the first 32 bits of the variable:
(gdb) x/t s
0x8048434 <_IO_stdin_used+4>:   01101100011011000110010101001000
Examine the first 24 bytes of the variable in hex:
(gdb) x/3x s
0x8048434 <_IO_stdin_used+4>:   0x6c6c6548      0x6f57206f      0x0a646c72

6.2 How do I see what is in the processor registers?

Use the info registers command. The output of this command depends on the hardware architecture. The following is part of the output on an intel machine:

(gdb) info registers
eax            0x40123460       1074934880
ecx            0x1      1
edx            0x80483c0        134513600
ebx            0x40124bf4       1074940916
esp            0xbffffa74       0xbffffa74
ebp            0xbffffa8c       0xbffffa8c
esi            0x400165e4       1073833444
...

6.3 How do I debug with a core file?

When your program segfaults and leaves a core dump file, you can use gdb to look at the program state when it crashed. Use the core command to load a core file. The argument to the core command is the filename of the core dump file, which is usually "core", making the full command core core.

[sgupta@rhel6x64 socket]$ myprogram
Segmentation fault (core dumped)
[sgupta@rhel6x64 socket]$ gdb myprogram
...
(gdb) core core
...

6.4 How do I step through my code at the instruction level?

There are two commands, nexti and stepi, that work similar to next and step. See the usage of those commands for an idea of how to use these two

6.5 How do I see the assembly code my program is running?


Use the disassemble command. The argument to this command is a memory address. Here is an example of the disassembly for the main function of a simple program on an intel machine:
(gdb) disassemble main

Dump of assembler code for function main:

0x80483c0 <main>:       push   %ebp
0x80483c1 <main+1>:     mov    %esp,%ebp
0x80483c3 <main+3>:     sub    $0x18,%esp
0x80483c6 <main+6>:     movl   $0x0,0xfffffffc(%ebp)
0x80483cd <main+13>:    mov    0xfffffffc(%ebp),%eax
0x80483d0 <main+16>:    movb   $0x7,(%eax)
0x80483d3 <main+19>:    xor    %eax,%eax
0x80483d5 <main+21>:    jmp    0x80483d7 <main+23>
0x80483d7 <main+23>:    leave
0x80483d8 <main+24>:    ret   
End of assembler dump.

7.1 Example Debugging Session: Infinite Loop Example


We are going to use gdb to discover where the infinite loop in the following program is. It may be obvious to you on inspection, but it is instructive to use gdb to find it. The program should print out all the alphanumeric (letter and number) characters in it's input.

1 : #include <stdio.h>
2 : #include <ctype.h>
3 :
4 : int main(int argc, char **argv)
5 : {
6 :   char c;
7 :
8 :   c = fgetc(stdin);
9 :   while(c != EOF){
10:

11:       if(isalnum(c))
12:          printf("%c", c);
13:        else
14:          c = fgetc(stdin);
15:   }
16:
17:   return 1;
18: }



The first step is to compile the program with debugging flags:
 
[sgupta@rhel6x64 socket]$ gcc -g inf.c
 
Now if we run this program and enter a few characters followed by a newline, we discover something is amiss. Note that you will have to press Ctrl-C to stop this program once the infinite loop starts!

[sgupta@rhel6x64 socket]$ a.out

bob
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
...
 

Obviously, we have a problem. Lets load up gdb:
 
[sgupta@rhel6x64 socket]$ gdb a.out
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
(gdb)
 

To find the problem, we'll set off the infinite loop, and then press Ctrl-C to send the program a SIGINT. Gdb will trap this signal and stop program execution.

(gdb) run
Starting program: /home/dgawd/cpsc/363/a.out
moo
mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
....
mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
Program received signal SIGINT, Interrupt.
0x400d8dc4 in write () from /lib/libc.so.6
(gdb)
 

Now the program is stopped and we can see where we are. We will use the backtrace command to examine the stack. The output of this command depends on your C libraries and exactly where the program was when you sent it the SIGINT. Mine looks like this:

(gdb) backtrace
#0  0x400d8dc4 in write () from /lib/libc.so.6
#1  0x40124bf4 in __check_rhosts_file () from /lib/libc.so.6
#2  0x40086ee8 in _IO_do_write () from /lib/libc.so.6
#3  0x40086e46 in _IO_do_write () from /lib/libc.so.6
#4  0x40087113 in _IO_file_overflow () from /lib/libc.so.6
#5  0x40087de5 in __overflow () from /lib/libc.so.6
#6  0x40069696 in vfprintf () from /lib/libc.so.6
#7  0x40070d76 in printf () from /lib/libc.so.6
#8  0x80484c2 in main (argc=1, argv=0xbffffaf4) at inf.c:12
#9  0x40037f5c in __libc_start_main () from /lib/libc.so.6

From this output, we can see that the program stopped in the write() system call inside the C library. But what we really want to see is where we are in main, so we are going to switch to frame 8:

(gdb) frame 8
#8  0x80484c2 in main (argc=1, argv=0xbffffaf4) at inf.c:12
12                printf("%c", c);
From the output, we know that the value of c is probably 'm', but lets check anyway:
(gdb) print c
$1 = 109 'm'
 

Now we have to find the loop. We use several iterations of the 'next' command to watch what is happening. Note that we have to work our way up the call stack back to main(). The next command will exit any functions we can't debug (like C library functions). We could also use the finish command here.
 

(gdb) next
 

Single stepping until exit from function write,
which has no line number information.
 

0x40087778 in _IO_file_write () from /lib/libc.so.6
(gdb) next
Single stepping until exit from function _IO_file_write,
which has no line number information.
0x40086ee8 in _IO_do_write () from /lib/libc.so.6
.....
.....
(gdb)
Single stepping until exit from function printf,
which has no line number information.
main (argc=1, argv=0xbffffaf4) at inf.c:15
15        }
Ok, now we are inside main(). We run the next command several more times to watch the program execute.
(gdb) n
11              if(isalnum(c))
(gdb)
12                printf("%c", c);
(gdb)
15        }
(gdb)
11              if(isalnum(c))
(gdb)
12                printf("%c", c);
(gdb) n
15        }
(gdb)
11              if(isalnum(c))
(gdb)
12                printf("%c", c);
 

Notice a pattern? The same two lines of code are executing over and over. This means we are looping, inside the while loop on line 9. Now, the value of 'c' is not changed in these lines. Maybe we should look back at our program:

11:        if(isalnum(c))
12:          printf("%c", c);
13:     else
14:          c = fgetc(stdin);
 

The lines being executed are 11 and 12. The test is always passing because the character is never changing. So the program is only reading characters until it finds an alphanumeric character, after which it never reaches the fgetc. But we always want to read the next character. Removing the 'else' on line 13 will fix the bug.

7.2 Example Debugging Session: Segmentation Fault Example
 

We are going to use gdb to figure out why the following program causes a segmentation fault. The program is meant to read in a line of text from the user and print it. However, we will see that in it's current state it doesn't work as expected...

1 : #include <stdio.h>
2 : #include <stdlib.h>

3 : int main(int argc, char **argv)
4 : {
5 :   char *buf;
6 :
7 :   buf = malloc(1<<31);
8 :
9 :   fgets(buf, 1024, stdin);
10:   printf("%s\n", buf);
11:
12:   return 1;
13: }



The first step is to compile the program with debugging flags:
 
[sgupta@rhel6x64 socket]$ gcc -g segfault.c
 

Now we run the program:
 

[sgupta@rhel6x64 socket]$ a.out
Hello World!
Segmentation fault
[sgupta@rhel6x64 socket]$
 

This is not what we want. Time to fire up gdb:
 

[sgupta@rhel6x64 socket]$ gdb a.out
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
(gdb)
We'll just run it and see what happens:
(gdb) run
Starting program: /home/dgawd/cpsc/363/a.out
test string

Program received signal SIGSEGV, Segmentation fault.
0x4007fc13 in _IO_getline_info () from /lib/libc.so.6

So we received the SIGSEGV signal from the operating system. This means that we tried to access an invalid memory address. Let's take a backtrace:

(gdb) backtrace
#0  0x4007fc13 in _IO_getline_info () from /lib/libc.so.6
#1  0x4007fb6c in _IO_getline () from /lib/libc.so.6
#2  0x4007ef51 in fgets () from /lib/libc.so.6
#3  0x80484b2 in main (argc=1, argv=0xbffffaf4) at segfault.c:10
#4  0x40037f5c in __libc_start_main () from /lib/libc.so.6
We are only interested in our own code here, so we want to switch to stack frame 3 and see where the program crashed:
(gdb) frame 3
#3  0x80484b2 in main (argc=1, argv=0xbffffaf4) at segfault.c:10
10        fgets(buf, 1024, stdin)

We crashed inside the call to fgets. In general, we can assume that library functions such as fgets work properly (if this isn't the case, we are in a lot of trouble). So the problem must be one of our arguments. You may not know that 'stdin' is a global variable that is created by the stdio libraries. So we can assume this one is ok. That leaves us with 'buf':

(gdb) print buf
$1 = 0x0

The value of buf is 0x0, which is the NULL pointer. This is not what we want - buf should point to the memory we allocated on line 8. So we're going to have to find out what happened there. First we want to kill the currently-running invocation of our program:

(gdb) kill
Kill the program being debugged? (y or n) y
Now set a breakpoint on line 8:
(gdb) break segfault.c:8
Breakpoint 1 at 0x8048486: file segfault.c, line 8.
Now run the program again:
(gdb) run
Starting program: /home/dgawd/cpsc/363/a.out

Breakpoint 1, main (argc=1, argv=0xbffffaf4) at segfault.c:8
8         buf = malloc(1<<31);
We're going to check the value of buf before the malloc call. Since buf wasn't initialized, the value should be garbage, and it is:
(gdb) print buf
$2 = 0xbffffaa8 "Èúÿ¿#\177\003@t`\001@\001"
Now step over the malloc call and examine buf again:
(gdb) next
10        fgets(buf, 1024, stdin);
(gdb) print buf
$3 = 0x0
 

After the call to malloc, buf is NULL. If you were to go check the man page for malloc, you would discover that malloc returns NULL when it cannot allocate the amount of memory requested. So our malloc must have failed. Let's go back and look at it again:

7 :   buf = malloc(1<<31);
 

Well, the value of the expression 1 << 31 (the integer 1 right-shifted 31 times) is 429497295, or 4GB (gigabytes). Very few machines have this kind of memory - mine only has 256MB. So of cousre malloc would fail. Furthermore, we are only reading in 1024 bytes in the fgets call. All that extra space would be wasted, even if we could allocate it. Change the 1<<31 to 1024 (or 1<<9), and the program will work as expected:
 

[sgupta@rhel6x64 socket]$
Hello World!
Hello World!
[sgupta@rhel6x64 socket]$
 
So now you know how to debug segmentation faults with gdb. This is extremely useful (I use it more often then I care to admit). The example also illustrated another very important point: ALWAYS CHECK THE RETURN VALUE OF MALLOC! Have a nice day.
How to Debug Using GDB. We are going to be using two programs to illustrate how GDB can be used to debug code.Debugging a program with a logical error. The first sample program has some logical errors. The program is supposed to output the summation of (X^0)/0! + (X^1)/1! + (X^2)/2! + (X^3)/3! + (X^4)/4! + ... + (X^n)/n!, given x and n as inputs. However the program outputs a value of infinity, regardless of the inputs. We will take you step by step through the debugging process and trace the errors:
See the sample program broken.cpp 
/*
Broken.cpp
*/
2.  #include <iostream>
3.  #include <cmath>
4.   
5.  using namespace std;
6.   
7.  int ComputeFactorial(int number) {
8.    int fact = 0;
9.   
10.   for (int j = 1; j <= number; j++) {
11.     fact = fact * j;
12.   }
13. 
14.   return fact;
15. }
16. 
17. double ComputeSeriesValue(double x, int n) {
18.    double seriesValue = 0.0;
19.    double xpow = 1;
20. 
21.    for (int k = 0; k <= n; k++) {
22.       seriesValue += xpow / ComputeFactorial(k);
23.       xpow = xpow * x;
24.    }
25. 
26.    return seriesValue;
27. }
28. 
29. int main() {
30.    cout << "This program is used to compute the value of the following series : " << endl;
31. 
32.    cout << "(x^0)/0! + (x^1)/1! + (x^2)/2! + (x^3)/3! + (x^4)/4! + ........ + (x^n)/n! " << endl;
33. 
34.    cout << "Please enter the value of x : " ;
35. 
36.    double x;
37.    cin >> x;
38. 
39.    int n;
40.    cout << endl << "Please enter an integer value for n : " ;
41.    cin >> n;
42.    cout << endl;
43. 
44.    double seriesValue = ComputeSeriesValue(x, n);
45.    cout << "The value of the series for the values entered is "
46.  << seriesValue << endl;
47. 
48.    return 0;
49.}


2. Compile the program and execute the program.

[sgupta@rhel6x64 socket]$ g++ -g broken.cpp -o broken
[sgupta@rhel6x64 socket]$ ./broken
Whatever the input, the output will be inf. The -g option is important because it enables meaningful GDB debugging.

3. Start the debugger

[sgupta@rhel6x64 socket]$ gdb broken

This only starts the debugger; it does not start running the program in the debugger.

4. Look at the source code and set a breakpoint at line 43

(gdb) b 43
which is
double seriesValue = ComputeSeriesValue(x, n);

5. Now, we start to run the program in the debugger.

(gdb) run

Note: If you need to supply the command-line arguments for the execution of the program, simply include them after the run command, just as normally done on the command line.

6. The program starts running and asks us for the input.

Let's enter the values as x=2 and n=3. The expected output value is 5. The following is a snapshot of the program running in the debugger:

This program is used to compute the value of the following series :
(x^0)/0! + (x^1)/1! + (x^2)/2! + (x^3)/3! + (x^4)/4! + ........ + (x^n)/n!
Please enter the value of x : 2

Please enter an integer value for n : 3

Breakpoint 1, main () at broken.cpp:43
43  double seriesValue = ComputeSeriesValue(x, n);

Note that the program execution stopped at our first (and only) breakpoint.

7. Step into the ComputeSeriesValue() function

To step into a function call, we use the following command:

(gdb) step
ComputeSeriesValue (x=2, n=3) at broken.cpp:17
17  double seriesValue=0.0;

At this point, the program control is at the first statement of the function ComputeSeriesValue (x=2, n=3)

8. Next let's step through the program until we get into ComputeFactorial.

(gdb) next
18  double xpow=1;
(gdb) n
20  for (int k = 0; k <= n; k++) {
(gdb)
21    seriesValue += xpow / ComputeFactorial(k) ;
(gdb) s
ComputeFactorial (number=0) at broken.cpp:7
7  int fact=0;

Here we use the next command, which is similar to step except it will step over (instead of into) functions. The distinction doesn't matter here since there are no functions. You may use the shortest, unambigious spelling of a GDB command to save some typing. Here we use n and s instead of next and step, respectively. If the command is simply a repeat of the previous command, you can just hit return, which will execute the last command. Finally, we step (with s) into ComputeFactorial(). (If we'd used next, it would have stepped over ComputeFactorial.)
18.     Where are we?

If you want to know where you are in the program's execution (and how, to some extent, you got there), you can view the contents of the stack using the backtrace command as follows:

(gdb) bt
#0  ComputeFactorial (number=0) at broken.cpp:7
#1  0x08048907 in ComputeSeriesValue (x=3, n=2) at broken.cpp:21
#2  0x08048a31 in main () at broken.cpp:43
19.     Watching changes We can step through the program and examine the values using the print command.
(gdb) n
9  for (int j = 0; j <= number; j++) {
(gdb) n
10    fact = fact * j;
(gdb) n
9  for (int j = 0; j <= number; j++) {
(gdb) print fact
$2 = 0
(gdb) n
13  return fact;
(gdb) quit

The print command (abbreviated p) reveals that the value of fact never changes. Note that the function is returning a value of 0 for the function call ComputeFactorial(number=0). This is an ERROR!
By taking a closer look at the values printed above, we realize that we are computing fact=fact * j where fact has been initialized to 0; fact should have been initialized to 1. We quit GDB with the quit command. Next we need to change the following line:

int fact = 1;

Recompile the code and run it, you will get the expected output.

Debugging a program that produces a core dum. This program causes a core dump due to a segmentation fault. We will try to trace the reason for this core dump. Use the following program for this
testit.c :

#include <stdio.h>

void main()
{
        char *temp = "Paras";

        int i;
        i=0;

        temp[3]='F';

        for (i =0 ; i < 5 ; i++ )
               printf("%c\n", temp[i]);
}

1.  Compile the program using the following command.

    g++ testit.c -g -o testit 
2.  Run it normally, you should get the following result:

    Segmentation fault (core dumped)
 
3.  The core dump generates a file called corewhich can be used for debugging. Since, this program is really short, we will not need to set any breakpoints. Use the following command to start running the debugger to debug the core file produced by testit.


gdb testit core

The output of the above command should look like this:

bash$ gdb testit core
GNU gdb 19991004
Copyright 1998 Free Software
Core was generated by `testit'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libstdc++-libc6.1-1.so.2...done.
Reading symbols from /lib/libm.so.6...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
#0  0x804851a in main () at testit.c:10
10              temp[3]='F';       

4.  As we can see from the output above, the core dump was produced as a result of execution of the statement on line 10:

temp[3] =F;

Take a closer look at the declaration of temp on line 5 :

Line 5          char *temp = "Paras";

We find that  temp  is a char* which has been assigned a string literal, and so we cannot modify the contents of the literal as on line 10. This is what is causing a core dump

Sunday, August 14, 2011

indent man page unix


indent(1) - Linux man page

Name

indent - changes the appearance of a C program by inserting or deleting whitespace.

Synopsis

indent [options] [input-files]
indent [options] [single-input-file] [-o output-file]
indent --version

Description

This man page is generated from the file indent.texinfo. This is Edition of "The indent Manual", for Indent Version , last updated .
The indent program can be used to make code easier to read. It can also convert from one style of writing C to another.
indent understands a substantial amount about the syntax of C, but it also attempts to cope with incomplete and misformed syntax.
In version 1.2 and more recent versions, the GNU style of indenting is the default.

Options

-bad, --blank-lines-after-declarations
Force blank lines after the declarations.
See BLANK LINES.
-bap, --blank-lines-after-procedures
Force blank lines after procedure bodies.
See BLANK LINES.
-bbb, --blank-lines-before-block-comments
Force blank lines before block comments.
See BLANK LINES.
-bbo, --break-before-boolean-operator
Prefer to break long lines before boolean operators.
See BREAKING LONG LINES.
-bc, --blank-lines-after-commas
Force newline after comma in declaration.
See DECLARATIONS.
-bl, --braces-after-if-line
Put braces on line after if, etc.
See STATEMENTS.
-blin, --brace-indentn
Indent braces n spaces.
See STATEMENTS.
-bls, --braces-after-struct-decl-line
Put braces on the line after struct declaration lines.
See DECLARATIONS.
-br, --braces-on-if-line
Put braces on line with if, etc.
See STATEMENTS.
-brs, --braces-on-struct-decl-line
Put braces on struct declaration line.
See DECLARATIONS.
-bs, --Bill-Shannon, --blank-before-sizeof
Put a space between sizeof and its argument.
See STATEMENTS.
-cn, --comment-indentationn
Put comments to the right of code in column n.
See COMMENTS.
-cbin, --case-brace-indentationn
Indent braces after a case label N spaces.
See STATEMENTS.
-cdn, --declaration-comment-columnn
Put comments to the right of the declarations in column n.
See COMMENTS.
-cdb, --comment-delimiters-on-blank-lines
Put comment delimiters on blank lines.
See COMMENTS.
-cdw, --cuddle-do-while
Cuddle while of do {} while; and preceeding `}.
See COMMENTS.
-ce, --cuddle-else
Cuddle else and preceeding `}.
See COMMENTS.
-cin, --continuation-indentationn
Continuation indent of n spaces.
See STATEMENTS.
-clin, --case-indentationn
Case label indent of n spaces.
See STATEMENTS.
-cpn, --else-endif-columnn
Put comments to the right of #else and #endif statements in column n.
See COMMENTS.
-cs, --space-after-cast
Put a space after a cast operator.
See STATEMENTS.
-dn, --line-comments-indentationn
Set indentation of comments not to the right of code to n spaces.
See COMMENTS.
-bfda, --break-function-decl-args
Break the line before all arguments in a declaration.
See DECLARATIONS.
-bfde, --break-function-decl-args
Break the line after the last argument in a declaration.
See DECLARATIONS.
-din, --declaration-indentationn
Put variables in column n.
See DECLARATIONS.
-fc1, --format-first-column-comments
Format comments in the first column.
See COMMENTS.
-fca, --format-all-comments
Do not disable all formatting of comments.
See COMMENTS.
-gnu, --gnu-style
Use GNU coding style. This is the default.
See COMMON STYLES.
-hnl, --honour-newlines
Prefer to break long lines at the position of newlines in the input.
See BREAKING LONG LINES.
-in, --indent-leveln
Set indentation level to n spaces.
See INDENTATION.
-ipn, --parameter-indentationn
Indent parameter types in old-style function definitions by n spaces.
See INDENTATION.
-kr, --k-and-r-style
Use Kernighan & Ritchie coding style.
See COMMON STYLES.
-ln, --line-lengthn
Set maximum line length for non-comment lines to n.
See BREAKING LONG LINES.
-lcn, --comment-line-lengthn
Set maximum line length for comment formatting to n.
See COMMENTS.
-lp, --continue-at-parentheses
Line up continued lines at parentheses.
See INDENTATION.
-lps, --leave-preprocessor-space
Leave space between `# and preprocessor directive.
See INDENTATION.
-nlps, --remove-preprocessor-space
Remove space between `# and preprocessor directive.
See INDENTATION.
-nbad, --no-blank-lines-after-declarations
Do not force blank lines after declarations.
See BLANK LINES.
-nbap, --no-blank-lines-after-procedures
Do not force blank lines after procedure bodies.
See BLANK LINES.
-nbbo, --break-after-boolean-operator
Do not prefer to break long lines before boolean operators.
See BREAKING LONG LINES.
-nbc, --no-blank-lines-after-commas
Do not force newlines after commas in declarations.
See DECLARATIONS.
-nbfda, --dont-break-function-decl-args
Dont put each argument in a function declaration on a seperate line.
See DECLARATIONS.
-ncdb, --no-comment-delimiters-on-blank-lines
Do not put comment delimiters on blank lines.
See COMMENTS.
-ncdw, --dont-cuddle-do-while
Do not cuddle } and the while of a do {} while;.
See STATEMENTS.
-nce, --dont-cuddle-else
Do not cuddle } and else.
See STATEMENTS.
-ncs, --no-space-after-casts
Do not put a space after cast operators.
See STATEMENTS.
-nfc1, --dont-format-first-column-comments
Do not format comments in the first column as normal.
See COMMENTS.
-nfca, --dont-format-comments
Do not format any comments.
See COMMENTS.
-nhnl, --ignore-newlines
Do not prefer to break long lines at the position of newlines in the input.
See BREAKING LONG LINES.
-nip, --no-parameter-indentation
Zero width indentation for parameters.
See INDENTATION.
-nlp, --dont-line-up-parentheses
Do not line up parentheses.
See STATEMENTS.
-npcs, --no-space-after-function-call-names
Do not put space after the function in function calls.
See STATEMENTS.
-nprs, --no-space-after-parentheses
Do not put a space after every ( and before every ).
See STATEMENTS.
-npsl, --dont-break-procedure-type
Put the type of a procedure on the same line as its name.
See DECLARATIONS.
-nsaf, --no-space-after-for
Do not put a space after every for.
See STATEMENTS.
-nsai, --no-space-after-if
Do not put a space after every if.
See STATEMENTS.
-nsaw, --no-space-after-while
Do not put a space after every while.
See STATEMENTS.
-nsc, --dont-star-comments
Do not put the `* character at the left of comments.
See COMMENTS.
-nsob, --leave-optional-blank-lines
Do not swallow optional blank lines.
See BLANK LINES.
-nss, --dont-space-special-semicolon
Do not force a space before the semicolon after certain statements. Disables `-ss.
See STATEMENTS.
-nut, --no-tabs
Use spaces instead of tabs.
See INDENTATION.
-nv, --no-verbosity
Disable verbose mode.
See MISCELLANEOUS OPTIONS.
-orig, --original
Use the original Berkeley coding style.
See COMMON STYLES.
-npro, --ignore-profile
Do not read `.indent.pro files.
See INVOKING INDENT.
-pcs, --space-after-procedure-calls
Insert a space between the name of the procedure being called and the `(.
See STATEMENTS.
-pin, --paren-indentationn
Specify the extra indentation per open parentheses ( when a statement is broken.See STATEMENTS.
-pmt, --preserve-mtime
Preserve access and modification times on output files.See MISCELLANEOUS OPTIONS.
-ppin, --preprocessor-indentationn
Request indentation of preprocessor conditional statements.
See INDENTATION.
-prs, --space-after-parentheses
Put a space after every ( and before every ).
See STATEMENTS.
-psl, --procnames-start-lines
Put the type of a procedure on the line before its name.
See DECLARATIONS.
-saf, --space-after-for
Put a space after each for.
See STATEMENTS.
-sai, --space-after-if
Put a space after each if.
See STATEMENTS.
-saw, --space-after-while
Put a space after each while.
See STATEMENTS.
-sbin, --struct-brace-indentationn
Indent braces of a struct, union or enum N spaces.
See STATEMENTS.
-sc, --start-left-side-of-comments
Put the `* character at the left of comments.
See COMMENTS.
-sob, --swallow-optional-blank-lines
Swallow optional blank lines.
See BLANK LINES.
-ss, --space-special-semicolon
On one-line for and while statments, force a blank before the semicolon.
See STATEMENTS.
-st, --standard-output
Write to standard output.
See INVOKING INDENT.
-T
Tell indent the name of typenames.
See DECLARATIONS.
-tsn, --tab-sizen
Set tab size to n spaces.
See INDENTATION.
-ut, --use-tabs
Use tabs. This is the default.
See INDENTATION.
-v, --verbose
Enable verbose mode.
See MISCELLANEOUS OPTIONS.
-version
Output the version number of indent.
See MISCELLANEOUS OPTIONS.

Invoking Indent

As of version 1.3, the format of the indent command is:
indent [options] [input-files]
 
indent [options] [single-input-file] [-o output-file]
This format is different from earlier versions and other versions of indent.
In the first form, one or more input files are specified. indent makes a backup copy of each file, and the original file is replaced with its indented version. See BACKUP FILES, for an explanation of how backups are made.
In the second form, only one input file is specified. In this case, or when the standard input is used, you may specify an output file after the `-o option.
To cause indent to write to standard output, use the `-st option. This is only allowed when there is only one input file, or when the standard input is used.
If no input files are named, the standard input is read for input. Also, if a filename named `- is specified, then the standard input is read.
As an example, each of the following commands will input the program `slithy_toves.c and write its indented text to `slithy_toves.out:
indent slithy_toves.c -o slithy_toves.out
 
indent -st slithy_toves.c > slithy_toves.out
 
cat slithy_toves.c | indent -o slithy_toves.out
Most other options to indent control how programs are formatted. As of version 1.2, indent also recognizes a long name for each option name. Long options are prefixed by either `-- or `+. [ `+ is being superseded by `-- to maintain consistency with the POSIX standard.] In most of this document, the traditional, short names are used for the sake of brevity. See OPTION SUMMARY, for a list of options, including both long and short names.
Here is another example:
indent -br test/metabolism.c -l85
This will indent the program `test/metabolism.c using the `-br and `-l85 options, write the output back to `test/metabolism.c, and write the original contents of `test/metabolism.c to a backup file in the directory `test.
Equivalent invocations using long option names for this example would be:
indent --braces-on-if-line --line-length185 test/metabolism.c
 
indent +braces-on-if-line +line-length185 test/metabolism.c
If you find that you often use indent with the same options, you may put those options into a file named `.indent.pro. indent will look for a profile file in three places. First it will check the environment variable INDENT_PROFILE. If that exists its value is expected to name the file that is to be used. If the environment variable does not exist, indent looks for `.indent.pro in the current directory and use that if found. Finally indent will search your home directory for `.indent.pro and use that file if it is found. This behaviour is different from that of other versions of indent, which load both files if they both exist.
The format of `.indent.pro is simply a list of options, just as they would appear on the command line, separated by white space (tabs, spaces, and newlines). Options in `.indent.pro may be surrounded by C or C++ comments, in which case they are ignored.
Command line switches are handled after processing `.indent.pro. Options specified later override arguments specified earlier, with one exception: Explicitly specified options always override background options (See COMMON STYLES). You can prevent indent from reading an `.indent.pro file by specifying the `-npro option.

Backup Files

As of version 1.3, GNU indent makes GNU-style backup files, the same way GNU Emacs does. This means that either simple or numbered backup filenames may be made.
Simple backup file names are generated by appending a suffix to the original file name. The default for this suffix is the one-character string `~ (tilde). Thus, the backup file for `python.c would be `python.c~.
Instead of the default, you may specify any string as a suffix by setting the environment variable SIMPLE_BACKUP_SUFFIX to your preferred suffix.
Numbered backup versions of a file `momeraths.c look like `momeraths.c.~23~, where 23 is the version of this particular backup. When making a numbered backup of the file `src/momeraths.c, the backup file will be named `src/momeraths.c.~V~, where V is one greater than the highest version currently existing in the directory `src. The environment variable VERSION_WIDTH controls the number of digits, using left zero padding when necessary. For instance, setting this variable to "2" will lead to the backup file being named `momeraths.c.~04~.
The type of backup file made is controlled by the value of the environment variable VERSION_CONTROL. If it is the string `simple, then only simple backups will be made. If its value is the string `numbered, then numbered backups will be made. If its value is `numbered-existing, then numbered backups will be made if there already exist numbered backups for the file being indented; otherwise, a simple backup is made. If VERSION_CONTROL is not set, then indent assumes the behaviour of `numbered-existing.
Other versions of indent use the suffix `.BAK in naming backup files. This behaviour can be emulated by setting SIMPLE_BACKUP_SUFFIX to `.BAK.
Note also that other versions of indent make backups in the current directory, rather than in the directory of the source file as GNU indent now does.

Common Styles

There are several common styles of C code, including the GNU style, the Kernighan & Ritchie style, and the original Berkeley style. A style may be selected with a single background option, which specifies a set of values for all other options. However, explicitly specified options always override options implied by a background option.
As of version 1.2, the default style of GNU indent is the GNU style. Thus, it is no longer necessary to specify the option `-gnu to obtain this format, although doing so will not cause an error. Option settings which correspond to the GNU style are:
-nbad -bap -nbc -bbo -bl -bli2 -bls -ncdb -nce -cp1 -cs -di2
-ndj -nfc1 -nfca -hnl -i2 -ip5 -lp -pcs -nprs -psl -saf -sai
-saw -nsc -nsob
The GNU coding style is that preferred by the GNU project. It is the style that the GNU Emacs C mode encourages and which is used in the C portions of GNU Emacs. (People interested in writing programs for Project GNU should get a copy of "The GNU Coding Standards", which also covers semantic and portability issues such as memory usage, the size of integers, etc.)
The Kernighan & Ritchie style is used throughout their well-known book "The C Programming Language". It is enabled with the `-kr option. The Kernighan & Ritchie style corresponds to the following set of options:
-nbad -bap -bbo -nbc -br -brs -c33 -cd33 -ncdb -ce -ci4 -cli0
-cp33 -cs -d0 -di1 -nfc1 -nfca -hnl -i4 -ip0 -l75 -lp -npcs
-nprs -npsl -saf -sai -saw -nsc -nsob -nss
Kernighan & Ritchie style does not put comments to the right of code in the same column at all times (nor does it use only one space to the right of the code), so for this style indent has arbitrarily chosen column 33.
The style of the original Berkeley indent may be obtained by specifying `-orig (or by specifying `--original, using the long option name). This style is equivalent to the following settings:
-nbad -nbap -bbo -bc -br -brs -c33 -cd33 -cdb -ce -ci4 -cli0
-cp33 -di16 -fc1 -fca -hnl -i4 -ip4 -l75 -lp -npcs -nprs -psl
-saf -sai -saw -sc -nsob -nss -ts8

Blank Lines

Various programming styles use blank lines in different places. indent has a number of options to insert or delete blank lines in specific places.
The `-bad option causes indent to force a blank line after every block of declarations. The `-nbad option causes indent not to force such blank lines.
The `-bap option forces a blank line after every procedure body. The `-nbap option forces no such blank line.
The `-bbb option forces a blank line before every boxed comment (See COMMENTS.) The `-nbbb option does not force such blank lines.
The `-sob option causes indent to swallow optional blank lines (that is, any optional blank lines present in the input will be removed from the output). If the `-nsob is specified, any blank lines present in the input file will be copied to the output file.

--blank-lines-after-declarations

The `-bad option forces a blank line after every block of declarations. The `-nbad option does not add any such blank lines.
For example, given the input
char *foo;
char *bar;
/* This separates blocks of declarations.  */
int baz;
indent -bad produces
char *foo;
char *bar;
 
/* This separates blocks of declarations.  */
int baz;
and indent -nbad produces
char *foo;
char *bar;
/* This separates blocks of declarations.  */
int baz;

--blank-lines-after-procedures

The `-bap option forces a blank line after every procedure body.
For example, given the input
int
foo ()
{
  puts("Hi");
}
/* The procedure bar is even less interesting.  */
char *
bar ()
{
  puts("Hello");
}
indent -bap produces
int
foo ()
{
  puts ("Hi");
}
 
/* The procedure bar is even less interesting.  */
char *
bar ()
{
  puts ("Hello");
}
and indent -nbap produces
int
foo ()
{
  puts ("Hi");
}
/* The procedure bar is even less interesting.  */
char *
bar ()
{
  puts ("Hello");
}
No blank line will be added after the procedure foo.

Comments

indent formats both C and C++ comments. C comments are begun with `/*, terminated with `*/ and may contain newline characters. C++ comments begin with the delimiter `// and end at the newline.
indent handles comments differently depending upon their context. indent attempts to distinguish between comments which follow statements, comments which follow declarations, comments following preprocessor directives, and comments which are not preceded by code of any sort, i.e., they begin the text of the line (although not neccessarily in column 1).
indent further distinguishes between comments found outside of procedures and aggregates, and those found within them. In particular, comments beginning a line found within a procedure will be indented to the column at which code is currently indented. The exception to this a comment beginning in the leftmost column; such a comment is output at that column.
indent attempts to leave boxed comments unmodified. The general idea of such a comment is that it is enclosed in a rectangle or ``box�� of stars or dashes to visually set it apart. More precisely, boxed comments are defined as those in which the initial `/* is followed immediately by the character `*, `=, `_, or `-, or those in which the beginning comment delimiter (`/*) is on a line by itself, and the following line begins with a `* in the same column as the star of the opening delimiter.
Examples of boxed comments are:
/**********************
 * Comment in a box!! *
 **********************/
 
      /*
        * A different kind of scent,
        * for a different kind of comment.
        */
indent attempts to leave boxed comments exactly as they are found in the source file. Thus the indentation of the comment is unchanged, and its length is not checked in any way. The only alteration made is that an embedded tab character may be converted into the appropriate number of spaces.
If the `-bbb option is specified, all such boxed comments will be preceded by a blank line, unless such a comment is preceded by code.
Comments which are not boxed comments may be formatted, which means that the line is broken to fit within a right margin and left-filled with whitespace. Single newlines are equivalent to a space, but blank lines (two or more newlines in a row) are taken to mean a paragraph break. Formatting of comments which begin after the first column is enabled with the `-fca option. To format those beginning in column one, specify `-fc1. Such formatting is disabled by default.
The right margin for formatting defaults to 78, but may be changed with the `-lc option. If the margin specified does not allow the comment to be printed, the margin will be automatically extended for the duration of that comment. The margin is not respected if the comment is not being formatted.
If the comment begins a line (i.e., there is no program text to its left), it will be indented to the column it was found in unless the comment is within a block of code. In that case, such a comment will be aligned with the indented code of that block (unless the comment began in the first column). This alignment may be affected by the `-d option, which specifies an amount by which such comments are moved to the left, or unindented. For example, `-d2 places comments two spaces to the left of code. By default, comments are aligned with code, unless they begin in the first column, in which case they are left there by default --- to get them aligned with the code, specify `-fc1.
Comments to the right of code will appear by default in column 33. This may be changed with one of three options. `-c will specify the column for comments following code, `-cd specifies the column for comments following declarations, and `-cp specifies the column for comments following preprocessor directives #else and #endif.
If the code to the left of the comment exceeds the beginning column, the comment column will be extended to the next tabstop column past the end of the code, or in the case of preprocessor directives, to one space past the end of the directive. This extension lasts only for the output of that particular comment.
The `-cdb option places the comment delimiters on blank lines. Thus, a single line comment like /* Loving hug */ can be transformed into:
/*
   Loving hug
 */
Stars can be placed at the beginning of multi-line comments with the `-sc option. Thus, the single-line comment above can be transformed (with `-cdb -sc) into:
/*
 * Loving hug
 */

Statements

The `-br or `-bl option specifies how to format braces.
The `-br option formats statement braces like this:
if (x > 0) {
  x--;
}
The `-bl option formats them like this:
if (x > 0)
  {
    x--;
  }
If you use the `-bl option, you may also want to specify the `-bli option. This option specifies the number of spaces by which braces are indented. `-bli2, the default, gives the result shown above. `-bli0 results in the following:
if (x > 0)
{
  x--;
}
If you are using the `-br option, you probably want to also use the `-ce option. This causes the else in an if-then-else construct to cuddle up to the immediately preceding `}. For example, with `-br -ce you get the following:
if (x > 0) {
  x--;
} else {
  fprintf (stderr, "...something wrong?\n");
}
With `-br -nce that code would appear as
if (x > 0) {
  x--;
}
else {
  fprintf (stderr, "...something wrong?\n");
}
This causes the while in a do-while loop to cuddle up to the immediately preceding `}. For example, with `-cdw you get the following:
do {
  x--;
} while (x);
With `-ncdw that code would appear as
do {
  x--;
}
while (x);
The `-cli option specifies the number of spaces that case labels should be indented to the right of the containing switch statement.
The default gives code like:
switch (i)
  {
  case 0:
    break;
  case 1:
    {
      ++i;
    }
  default:
    break;
  }
Using the `-cli2 that would become:
switch (i)
  {
    case 0:
      break;
    case 1:
      {
        ++i;
      }
    default:
      break;
  }
The indentation of the braces below a case statement can be controlled with the `-cbin option. For example, using `-cli2 -cbi0 results in:
switch (i)
  {
    case 0:
      break;
    case 1:
    {
      ++i;
    }
    default:
      break;
  }
If a semicolon is on the same line as a for or while statement, the `-ss option will cause a space to be placed before the semicolon. This emphasizes the semicolon, making it clear that the body of the for or while statement is an empty statement. `-nss disables this feature.
The `-pcs option causes a space to be placed between the name of the procedure being called and the `( (for example, puts ("Hi");. The `-npcs option would give puts("Hi");).
If the `-cs option is specified, indent puts a space after a cast operator.
The `-bs option ensures that there is a space between the keyword sizeof and its argument. In some versions, this is known as the `Bill_Shannon option.
The `-saf option forces a space between an for and the following parenthesis. This is the default.
The `-sai option forces a space between an if and the following parenthesis. This is the default.
The `-saw option forces a space between an while and the following parenthesis. This is the default.
The `-prs option causes all parentheses to be seperated with a space from the what is between them. For example, using `-prs results in code like:
while ( ( e_code - s_code ) < ( dec_ind - 1 ) )
  {
    set_buf_break ( bb_dec_ind );
    *e_code++ =  ;
  }

Declarations

By default indent will line up identifiers, in the column specified by the `-di option. For example, `-di16 makes things look like:
int             foo;
char           *bar;
Using a small value (such as one or two) for the `-di option can be used to cause the identifiers to be placed in the first available position; for example:
int foo;
char *bar;
The value given to the `-di option will still affect variables which are put on separate lines from their types, for example `-di2 will lead to:
int
  foo;
If the `-bc option is specified, a newline is forced after each comma in a declaration. For example,
int a,
  b,
  c;
With the `-nbc option this would look like
int a, b, c;
The `-bfda option causes a newline to be forced after the comma separating the arguments of a function declaration. The arguments will appear at one indention level deeper than the function declaration. This is particularly helpful for functions with long argument lists. The option `-bfde causes a newline to be forced before the closing bracket of the function declaration. For both options the n setting is the default: -nbdfa and -nbdfe.
For example,
void foo (int arg1, char arg2, int *arg3, long arg4, char arg5);
With the `-bfda option this would look like
void foo (
    int arg1,
    char arg2,
    int *arg3,
    long arg4,
    char arg5);
With, in addition, the `-bfde option this would look like
void foo (
    int arg1,
    char arg2,
    int *arg3,
    long arg4,
    char arg5
    );
The `-psl option causes the type of a procedure being defined to be placed on the line before the name of the procedure. This style is required for the etags program to work correctly, as well as some of the c-mode functions of Emacs.
You must use the `-T option to tell indent the name of all the typenames in your program that are defined by typedef. `-T can be specified more than once, and all names specified are used. For example, if your program contains
typedef unsigned long CODE_ADDR;
typedef enum {red, blue, green} COLOR;
you would use the options `-T CODE_ADDR -T COLOR.
The `-brs or `-bls option specifies how to format braces in struct declarations. The `-brs option formats braces like this:
struct foo {
  int x;
};
The `-bls option formats them like this:
struct foo
{
  int x;
};

Indentation

One issue in the formatting of code is how far each line should be indented from the left margin. When the beginning of a statement such as if or for is encountered, the indentation level is increased by the value specified by the `-i option. For example, use `-i8 to specify an eight character indentation for each level. When a statement is broken across two lines, the second line is indented by a number of additional spaces specified by the `-ci option. `-ci defaults to 0. However, if the `-lp option is specified, and a line has a left parenthesis which is not closed on that line, then continuation lines will be lined up to start at the character position just after the left parenthesis. This processing also applies to `[ and applies to `{ when it occurs in initialization lists. For example, a piece of continued code might look like this with `-nlp -ci3 in effect:
p1 = first_procedure (second_procedure (p2, p3),
   third_procedure (p4, p5));
With `-lp in effect the code looks somewhat clearer:
p1 = first_procedure (second_procedure (p2, p3),
                      third_procedure (p4, p5));
When a statement is broken in between two or more paren pairs (...), each extra pair causes the indentation level extra indentation:
if ((((i < 2 &&
        k > 0) || p == 0) &&
    q == 1) ||
  n = 0)
The option `-ipN can be used to set the extra offset per paren. For instance, `-ip0 would format the above as:
if ((((i < 2 &&
  k > 0) || p == 0) &&
  q == 1) ||
  n = 0)
indent assumes that tabs are placed at regular intervals of both input and output character streams. These intervals are by default 8 columns wide, but (as of version 1.2) may be changed by the `-ts option. Tabs are treated as the equivalent number of spaces.
The indentation of type declarations in old-style function definitions is controlled by the `-ip parameter. This is a numeric parameter specifying how many spaces to indent type declarations. For example, the default `-ip5 makes definitions look like this:
char *
create_world (x, y, scale)
     int x;
     int y;
     float scale;
{
  . . .
}
For compatibility with other versions of indent, the option `-nip is provided, which is equivalent to `-ip0.
ANSI C allows white space to be placed on preprocessor command lines between the character `# and the command name. By default, indent removes this space, but specifying the `-lps option directs indent to leave this space unmodified. The option `-ppi overrides `-nlps and `-lps.
This option can be used to request that preprocessor conditional statements can be indented by to given number of spaces, for example with the option `-ppi 3
#if X
#if Y
#define Z 1
#else
#define Z 0
#endif
#endif
becomes
#if X
#   if Y
#      define Z 1
#   else
#      define Z 0
#   endif
#endif

Breaking Long Lines

With the option `-ln, or `--line-lengthn, it is possible to specify the maximum length of a line of C code, not including possible comments that follow it.
When lines become longer then the specified line length, GNU indent tries to break the line at a logical place. This is new as of version 2.1 however and not very intelligent or flexible yet.
Currently there are two options that allows one to interfere with the algorithm that determines where to break a line.
The `-bbo option causes GNU indent to prefer to break long lines before the boolean operators && and ||. The `-nbbo option causes GNU indent not have that preference. For example, the default option `-bbo (together with `--line-length60 and `--ignore-newlines) makes code look like this:
if (mask
    && ((mask[0] == \0)
        || (mask[1] == \0
            && ((mask[0] == 0) || (mask[0] == *)))))
Using the option `-nbbo will make it look like this:
if (mask &&
    ((mask[0] == \0) ||
     (mask[1] == \0 &&
      ((mask[0] == 0) || (mask[0] == *)))))
The default `-hnl, however, honours newlines in the input file by giving them the highest possible priority to break lines at. For example, when the input file looks like this:
if (mask
    && ((mask[0] == \0)
    || (mask[1] == \0 && ((mask[0] == 0) || (mask[0] == *)))))
then using the option `-hnl, or `--honour-newlines, together with the previously mentioned `-nbbo and `--line-length60, will cause the output not to be what is given in the last example but instead will prefer to break at the positions where the code was broken in the input file:
if (mask
    && ((mask[0] == \0)
        || (mask[1] == \0 &&
            ((mask[0] == 0) || (mask[0] == *)))))
The idea behind this option is that lines which are too long, but are already broken up, will not be touched by GNU indent. Really messy code should be run through indent at least once using the `--ignore-newlines option though.

Disabling Formatting

Formatting of C code may be disabled for portions of a program by embedding special control comments in the program. To turn off formatting for a section of a program, place the disabling control comment /* *INDENT-OFF* */ on a line by itself just before that section. Program text scanned after this control comment is output precisely as input with no modifications until the corresponding enabling comment is scanned on a line by itself. The disabling control comment is /* *INDENT-ON* */, and any text following the comment on the line is also output unformatted. Formatting begins again with the input line following the enabling control comment.
More precisely, indent does not attempt to verify the closing delimiter (*/) for these C comments, and any whitespace on the line is totally transparent.
These control comments also function in their C++ formats, namely // *INDENT-OFF* and // *INDENT-ON*.
It should be noted that the internal state of indent remains unchanged over the course of the unformatted section. Thus, for example, turning off formatting in the middle of a function and continuing it after the end of the function may lead to bizarre results. It is therefore wise to be somewhat modular in selecting code to be left unformatted.
As a historical note, some earlier versions of indent produced error messages beginning with *INDENT**. These versions of indent were written to ignore any input text lines which began with such error messages. I have removed this incestuous feature from GNU indent.

Miscellaneous Options

To find out what version of indent you have, use the command indent -version. This will report the version number of indent, without doing any of the normal processing.
The `-v option can be used to turn on verbose mode. When in verbose mode, indent reports when it splits one line of input into two more more lines of output, and gives some size statistics at completion.
The `-pmt option causes indent to preserve the access and modification times on the output files. Using this option has the advantage that running indent on all source and header files in a project wont cause make to rebuild all targets. This option is only available on Operating Systems that have the POSIX utime(2) function.

Bugs

Please report any bugs to bug-indent@gnu.org.
When indent is run twice on a file, with the same profile, it should never change that file the second time. With the current design of indent, this can not be guaranteed, and it has not been extensively tested.
indent does not understand C. In some cases this leads to the inability to join lines. The result is that running a file through indent is irreversible, even if the used input file was the result of running indent with a given profile (`.indent.pro).
While an attempt was made to get indent working for C++, it will not do a good job on any C++ source except the very simplest.
indent does not look at the given `--line-length option when writing comments to the output file. This results often in comments being put far to the right. In order to prohibit indent from joining a broken line that has a comment at the end, make sure that the comments start on the first line of the break.
indent does not count lines and comments (see the `-v option) when indent is turned off with /* *INDENT-OFF* */.
Comments of the form /*UPPERCASE*/ are not treated as comment but as an identifier, causing them to be joined with the next line. This renders comments of this type useless, unless they are embedded in the code to begin with.

Copyright

The following copyright notice applies to the indent program. The copyright and copying permissions for this manual appear near the beginning of `indent.texinfo and `indent.info, and near the end of `indent.1.
Copyright (c) 2001 David Ingamells.
Copyright (c) 1999 Carlo Wood.
Copyright (c) 1995, 1996 Joseph Arceneaux.
Copyright (c) 1989, 1992, 1993, 1994, 1995, 1996 Free Software Foundation
Copyright (c) 1985 Sun Microsystems, Inc.
Copyright (c) 1980 The Regents of the University of California.
Copyright (c) 1976 Board of Trustees of the University of Illinois.
All rights reserved.
 
Redistribution and use in source and binary forms are permitted
provided that the above copyright notice and this paragraph are
duplicated in all such forms and that any documentation,
advertising materials, and other materials related to such
distribution and use acknowledge that the software was developed
by the University of California, Berkeley, the University of Illinois,
Urbana, and Sun Microsystems, Inc.  The name of either University
or Sun Microsystems may not be used to endorse or promote products
derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED ``AS IS�� AND WITHOUT ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR
PURPOSE.

Options Cross Key

Here is a list of options alphabetized by long option, to help you find the corresponding short option.
--blank-lines-after-commas                      -bc
--blank-lines-after-declarations                -bad
--blank-lines-after-procedures                  -bap
--blank-lines-before-block-comments             -bbb
--braces-after-if-line                          -bl
--brace-indent                                  -bli
--braces-after-struct-decl-line                 -bls
--braces-on-if-line                             -br
--braces-on-struct-decl-line                    -brs
--break-after-boolean-operator                  -nbbo
--break-before-boolean-operator                 -bbo
--break-function-decl-args                      -bfda
--break-function-decl-args-end                  -bfde
--case-indentation                              -clin
--case-brace-indentation                        -cbin
--comment-delimiters-on-blank-lines             -cdb
--comment-indentation                           -cn
--continuation-indentation                      -cin
--continue-at-parentheses                       -lp
--cuddle-do-while                               -cdw
--cuddle-else                                   -ce
--declaration-comment-column                    -cdn
--declaration-indentation                       -din
--dont-break-function-decl-args                 -nbfda
--dont-break-function-decl-args-end             -nbfde
--dont-break-procedure-type                     -npsl
--dont-cuddle-do-while                          -ncdw
--dont-cuddle-else                              -nce
--dont-format-comments                          -nfca
--dont-format-first-column-comments             -nfc1
--dont-line-up-parentheses                      -nlp
--dont-space-special-semicolon                  -nss
--dont-star-comments                            -nsc
--else-endif-column                             -cpn
--format-all-comments                           -fca
--format-first-column-comments                  -fc1
--gnu-style                                     -gnu
--honour-newlines                               -hnl
--ignore-newlines                               -nhnl
--ignore-profile                                -npro
--indent-level                                  -in
--k-and-r-style                                 -kr
--leave-optional-blank-lines                    -nsob
--leave-preprocessor-space                      -lps
--line-comments-indentation                     -dn
--line-length                                   -ln
--no-blank-lines-after-commas                   -nbc
--no-blank-lines-after-declarations             -nbad
--no-blank-lines-after-procedures               -nbap
--no-blank-lines-before-block-comments          -nbbb
--no-comment-delimiters-on-blank-lines          -ncdb
--no-space-after-casts                          -ncs
--no-parameter-indentation                      -nip
--no-space-after-for
-nsaf
--no-space-after-function-call-names -npcs
--no-space-after-if
-nsai
--no-space-after-parentheses -nprs
--no-space-after-while
-nsaw
--no-tabs -nut
--no-verbosity -nv
--original -orig
--parameter-indentation -ipn
--paren-indentation -pin
--preprocessor-indentationn -ppin
--preserve-mtime
-pmt
--procnames-start-lines -psl
--remove-preprocessor-space -nlps
--space-after-cast -cs
--space-after-for
-saf
--space-after-if
-sai
--space-after-parentheses -prs
--space-after-procedure-calls -pcs
--space-after-while
-saw
--space-special-semicolon -ss
--standard-output -st
--start-left-side-of-comments -sc
--struct-brace-indentation -sbin
--swallow-optional-blank-lines -sob
--tab-size -tsn
--use-tabs -ut
--verbose -v

Return Value

Unknown

Files

$HOME/.indent.pro   holds default options for indent.

Authors

Carlo Wood
Joseph Arceneaux
Jim Kingdon
David Ingamells

History

Derived from the UCB program "indent".

Copying

Copyright (C) 1989, 1992, 1993, 1994, 1995, 1996 Free Software Foundation, Inc. Copyright (C) 1995, 1996 Joseph Arceneaux. Copyright (C) 1999 Carlo Wood. Copyright (C) 2001 David Ingamells.
Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies.