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