----- 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. Thanks, Dave -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
