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

[Dave Anderson]

----- 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?
> 
> 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?

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.

Thanks,
  Dave