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

----- Original Message ----- > 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 The extensions/eppic.c file is only there so that the extensions/Makefile will initiate the build of eppic.mk: $ cat extensions/eppic.c /* Place holder for proper working of the extension Makefile. Eppic crash application file is in eppic/applications/crash/eppic.c */ $ But you can put your actual ptdump.c file in the extensions subdirectory if you'd like.