KGTP (Linux Kernel debugger and tracer) 201100626 release

[Hui Zhu <teawater at gmail dot com>]

KGTP is a realtime and lightweight Linux Kernel GDB debugger and
tracer that uses Kprobe.

It makes Linux Kernel supply a GDB remote debug interface. Then GDB in
current machine or remote machine (see HOWTO#Make_GDB_connect_to_gtp")
can debug Linux through GDB tracepoint without stopping the Linux
Kernel.
And even if the board doesn't have GDB on it and doesn't have
interface for remote debug. It can debug the Linux Kernel using
offline debug (See HOWTO#Offline_debug).
Now, it supports X86-32, X86-64, MIPS and ARM.
http://www.tudou.com/programs/view/_p6VTgxmCRA/ This is a video(in
Chinese) to show how to use it.

Now, KGTP 20110626 release.
You can get the package for it from
http://kgtp.googlecode.com/files/kgtp_20110626.tar.bz2
or
svn co https://kgtp.googlecode.com/svn/tags/20110626

The main change of is:
Add some build options to make the KGTP mod can build with old version
Linux Kernel(the oldest kernel that I tested is 2.6.18).
--------------------
make FRAME_SIMPLE=1
--------------------
With this option, KGTP will use simple frame instead of ring buffer.
The simple frame doesn't support gtpframe_pipe.  Use it can make KGTP can build
with old Kernel that doesn't support ring buffer.

--------------------
make CLOCK_CYCLE=1
--------------------
With this option, $clock will return rdtsc value instead of local_clock.

--------------------
make LOCAL_CLOCK=1
--------------------
With this option, KGTP will define self local_clock function.

--------------------
make USE_PROC=1
--------------------
With this option, KGTP will use procfs instead of debugfs.

The options can use together, for example:
-----------------------------------
make FRAME_SIMPLE=1  CLOCK_CYCLE=1
-----------------------------------
This build command make KGTP build success with Linux Kernel 2.6.18.


Add per_cpu trace state variables.
Per_cpu trace state variables are special simple trace state variables.
When tracepoint action access to it, it will access to this CPU special trace
state variables.

It have 2 advantages:
1. The tracepoint actions that access to per_cpu trace state variables don't
have the race conditon issue.  So it don't need lock the spin lock for trace
state variables.  It is faster than simple trace state variables on multi-core
machine.
2. Write the action that count some CPU special thing with it is easier than
simple trace state variables.

To define per_cpu trace state variables, you need named it in
format "per_cpu_"+string+CPU_id.
Following example will define a series of per_cpu trace state variables
in a 4 COREs CPU machine with string "count":
-------------------------------------
tvariable $per_cpu_count0
tvariable $per_cpu_count1
tvariable $per_cpu_count2
tvariable $per_cpu_count3
-------------------------------------

You can use compatibility better way to do it:
-----------------------------------------
p $tmp=0
while $tmp<$cpu_number
 eval "tvariable $per_cpu_count%d",$tmp
 p $tmp=$tmp+1
end
-----------------------------------------

Tracepoint action can access anyone of a series of per_cpu trace state
variables.  KGTP will auto access the one of CPU that it running on.
For example:
----------------------------------------
trace vfs_read
actions
teval $per_cpu_count0=$per_cpu_count0+1
end
----------------------------------------
These GDB commands define a tracepoint that count the times that call vfs_read
of each CPU.

Thanks,
Hui