Random Learnings

As I keep browsing and reading things from time to time, these are the things which I come across.

1. cflow - Cflow helps you to get a function call trace or a function call graph in a .c file or a collection of source files. So, If you get a new project and there's a lot of code in it or say many files, what you can do is, get a call graph and get an idea in terms of funcgtions, what's happening. Obviously, there's no comparison to getting a function spec or a design doc, but since it's very difficult to get these things in a product companies, it might just help.
www.gnu.org/software/cflow/

2. ctags - Well, every body knows ctags. You can use ctags as a cross reference kind of a thing. Supposing, You see a function in your code and want to know where it's defined, as in, have a look at what that function does from within your code, ctags is helpful. I personally always used cscope for such things, but will give it a try too.
CTRL + ] for jumping to the symbol.
CTRL + T for jumping back from the symbol.
http://ctags.sourceforge.net/ctags.html

3. Profiling your program (prof/gprof) - This is done to analyse performance issues of your program. If you wanted to find out where your program is spending time, you can get your program monitored using profiling. You can use prof/gprof for this. Doing it requires the following -
# gcc -pg -o prog prog.c
The pg flag is for gprof.
Now, when You run the program, the program will be profiled.
# ./prog.c
It will produce a monitoring file in your current directory, which will tell you in terms of number of seconds, where your program spent time (Like I/O, mcopy etc.)
# ls -l will show a file called gmon.out, it may be mon.out for prof.
This will show the time split like follows -

 %   cumulative   self              self     total          
time   seconds   seconds    calls  ms/call  ms/call  name   
33.34      0.02     0.02     7208     0.00     0.00  open
16.67      0.03     0.01      244     0.04     0.12  offtime
16.67      0.04     0.01        8     1.25     1.25  memccpy
16.67      0.05     0.01        7     1.43     1.43  write
16.67      0.06     0.01                             mcount
 0.00      0.06     0.00      236     0.00     0.00  tzset
 0.00      0.06     0.00      192     0.00     0.00  tolower
 0.00      0.06     0.00       47     0.00     0.00  strlen
 0.00      0.06     0.00       45     0.00     0.00  strchr
 0.00      0.06     0.00        1     0.00    50.00  main
 0.00      0.06     0.00        1     0.00     0.00  memcpy
 0.00      0.06     0.00        1     0.00    10.11  print
 0.00      0.06     0.00        1     0.00     0.00  profil
 0.00      0.06     0.00        1     0.00    50.00  report

http://www.cs.utah.edu/dept/old/texinfo/as/gprof.html#SEC1


3. Memory Debugging Tools (Electric fence/valgrind) - Often times, even though you exceed the memory boundary allocated by you, you still don't get segmentation fault. This is because, the amount of memory you asked for, you might have been allocated little bit extra to align with page boundary and stuff. These kind of errors can be easily detected with Electric fence and valgrind.

To use electric fence, do the following -
# gcc prog.c -lefence

#./a.out
It'll throw segmentation fault wherever applies.
http://linux.maruhn.com/sec/electricfence.html (Here's the distro)

valgrind in my opinion is a more advanced tool.
You run your program under valgrind and it gives info about
access violation errors as well as memory leaks.
# valgrind --leak-check=yes -v prog.c
It'll give you verbose output describing a lot of stuff.
http://valgrind.org/