Re: [Crash-utility] Extensions: Dump log buffer of Intel Processor Trace
----- Original Message -----
Hi Dave,
The attached files are extension module to dump log buffer of Intel
Processor Trace from vmcore. Please consider placing this in the
extensions page.
[Overview of PT]
PT(Processor Trace) is a new feature of Intel CPU "Broadwell", it
captures information about program execution flow.[1]
Once Intel PT is enabled, the events which change program flow, like
branch instructions, exceptions, interruptions, traps and so on are
logged in the memory. This is very useful for debugging because we can
know the detailed behavior of software.
[About extension]
This extension retrieves log buff of PT from vmcore and saves it as a
file. 'ptdump' command can be used once this extension is loaded.
crash> extend extensions/ptdump.so
./extensions/ptdump.so: shared object loaded
crash> ptdump output_dir
[0] buffer dump: dump.0
[0] packet decode: decode.0
[1] buffer dump: dump.1
[1] packet decode: decode.1
(snipped)
In this case, output_dir directory is created, and then dump.N and
decode.N files are created in the directory for each cpus(N is cpu
number).
dump.N: raw data of PT
decode.N: result of PT packet decoder
dump.N is binary data and it is not human readable. decode.N is
generated by fastdecode[2], which is PT packet dumper created by Andi
Kleen. It's useful for checking what kinds of packets are included in
dump.N. I'll update extension using PT library(libipt[3]) to generate
more useful file for investigation.
[Build extension]
To build the module from the top-level crash-<version> directory, enter:
$ tar xvf ptdump-1.0.0.tar.gz
$ mv ptdump-1.0.0/* extensions
$ make extensions
[1] https://software.intel.com/en-us/blogs/2013/09/18/processor-tracing
[2] https://github.com/andikleen/simple-pt
[3] https://github.com/01org/processor-trace
Thanks,
Takao Indoh
Hi Takao,
I certainly can add this to the extensions subdirectory. However
I do have a couple suggestions with respect to the build procedure:
$ tar xvf $dl/ptdump-1.0.0.tar.gz
ptdump-1.0.0/
ptdump-1.0.0/fastdecode.c
ptdump-1.0.0/map.c
ptdump-1.0.0/map.h
ptdump-1.0.0/ptdump.c
ptdump-1.0.0/ptdump.mk
$ mv ptdump-1.0.0/* extensions
$ make extensions
gcc -Wall -g -nostartfiles -shared -rdynamic -o fastdecode.so fastdecode.c -fPIC
-DX86_64 -DLZO -DSNAPPY -DGDB_7_6
gcc -DLZO -DSNAPPY -Wall -I.. -fPIC -DX86_64 -c -o ptdump.o ptdump.c
gcc -DLZO -DSNAPPY -Wall -I.. -fPIC -DX86_64 -c -o fastdecode.o fastdecode.c
gcc -DLZO -DSNAPPY -Wall -I.. -fPIC -DX86_64 -c -o map.o map.c
gcc -Wall -g -shared -rdynamic -o map.so map.c -fPIC -DX86_64 -DLZO -DSNAPPY -DGDB_7_6
$ ls -ltr extensions/*.so
-rwxrwxr-x 1 anderson anderson 17613 Jan 5 10:51 extensions/echo.so*
-rwxrwxr-x 1 anderson anderson 851633 Jan 5 10:51 extensions/eppic.so*
-rwxrwxr-x 1 anderson anderson 100465 Jan 5 10:51 extensions/trace.so*
-rwxrwxr-x 1 anderson anderson 112373 Jan 5 10:51 extensions/dminfo.so*
-rwxrwxr-x 1 anderson anderson 42358 Jan 5 10:51 extensions/snap.so*
-rwxrwxr-x 1 anderson anderson 15539 Jan 5 10:57 extensions/fastdecode.so*
-rwxrwxr-x 1 anderson anderson 21136 Jan 5 10:57 extensions/ptdump.so*
-rwxrwxr-x 1 anderson anderson 14880 Jan 5 10:57 extensions/map.so*
$
The build procedure shows the creation of the "map.so" and
"fastdecode.so"
shared objects, but does not show the creation of "ptdump.so", which is the
only object that actually gets loaded into a crash session, correct?
That build line gets hidden because of the "@if" clause:
@if [ $(ARCH) = "UNSUPPORTED" ]; then \
echo "ptdump: architecture not supported"; \
else \
gcc $(CFLAGS) $(TARGET_CFLAGS) $(COMMON_CFLAGS) -nostartfiles -shared
-rdynamic -o $@ $^ ; \
fi;
Can you fix that so that a user can actually see the build of ptdump.so?
Also, unlike the other extension modules, the ptdump files and build
procedure clutter up the extensions subdirectory. Since you do
not have a single ptdump.mk and ptdump.c file, would it be possible
for you to do the same kind of thing that the "eppic" module does,
where there would be an extensions/ptdump.mk file, which would reference
the sources in a "ptdump" subdirectory where all of the files can be
cleanly kept in one place?
Thanks,
Dave