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

On 2016/01/06 12:32, Dave Anderson wrote: > > > ----- 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 mean, fastdecode.so and map.so was created by mistake. They are not needed. This bug is fixed in new version. >> >> 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. I noticed that ptdump.so was not built if all *.c files are in extensions/ptdump directory. See extensions/Makefile for details. So, I place files like this. extensions/ptdump.mk extensions/ptdump.c extensions/ptdump/fastdecode.c extensions/ptdump/map.c extensions/ptdump/map.h I attach new version. Thanks, Takao Indoh