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

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

extensions/ptdump.mk extensions/ptdump/ptdump.c

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

----- Original Message ----- > 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 > Hi Takao, Nicely done! The module has been added to the extensions page: http://people.redhat.com/anderson/extensions.html#PTDUMP