[Crash-utility] Extensions: Dump log buffer of Intel Processor Trace
Takao Indoh
indou.takao at jp.fujitsu.com
Wed Jan 6 08:46:12 UTC 2016
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ptdump-1.0.0.tar.gz
Type: application/gzip
Size: 7210 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20160106/8c1eff3d/attachment.gz>
More information about the Crash-utility
mailing list