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

[Takao Indoh]

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

Or, as you said, all files except ptdump.mk should be placed in
extensions/ptdump directory?

Anyway I'll change ptdump.mk so that only ptdump.so is generated in
extensions and and other object files like *.o are not.

Thanks,
Takao Indoh