[Crash-utility] Extensions: Dump log buffer of Intel Processor Trace
Dave Anderson
anderson at redhat.com
Wed Jan 6 03:32:45 UTC 2016
----- 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
More information about the Crash-utility
mailing list