Re: [Crash-utility] Extensions: Dump log buffer of Intel Processor Trace

On 2016/01/06 1:42, Dave Anderson wrote: > > > ----- Original Message ----- >> >> >> ----- 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? Ok, I'll fix it. >> 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 > > > Hi Takao, > > Can you explain what fastdecode.so and map.so are used for? > > crash> extend ptdump.so > ./extensions/ptdump.so: shared object loaded > crash> extend fastdecode.so > extend: ./extensions/fastdecode.so: no commands registered: shared > object unloaded > crash> extend map.so > extend: ./extensions/map.so: no commands registered: shared object > unloaded > crash> > > I see fastdecode.o and map.o being included in the ptdump.so compile line, > but > don't see where fastdecode.so and map.so fit into the picture? fastdecode.so and map.so is not generated. Everything is included in ptdump.so. I'll change ptdump.mk like this so that unnecessary *.o file is not generated. gcc -Wall -I. -fPIC -DX86_64 -nostartfiles -shared -rdynamic \ -o ptdump.so *.c > > In any case, to clarify my request again, after installation, there should > be > these files: > > extensions/ptdump.mk > extensions/ptdump/ptdump.c > extensions/ptdump/fastdecode.c > extensions/ptdump/map.c > extensions/ptdump/map.h > > And after the build: > > extensions/ptdump.so > > All of the other .o and .so files should only exist in the extensions/ptdump > subdirectory. I see, I'll fix them and post updated version soon. I have one question. > extensions/ptdump.mk > extensions/ptdump/ptdump.c ptdump.c should be also placed in extensions/ptdump? In the case of eppic, the files seems to be placed like this: extensions/eppic.mk extensions/eppic.c extensions/eppic/* Therefore if I should do in the same manner, the files should be like this? extensions/ptdump.mk extensions/ptdump.c extensions/ptdump/fastdecode.c extensions/ptdump/map.c extensions/ptdump/map.h