----- "Sharyathi Nagesh" <sharyath(a)in.ibm.com&gt; wrote: It's not a new concept. If the extensions/Makefile sees a "local.c" file, it will then look for a "local.mk" file and invoke it. I applied your patch, and "make extensions" from the top-level directory works as expected (although the compilation fails as expected): # make extensions gcc -nostartfiles -shared -rdynamic -o local.so local.c -fPIC -ldw -L ../../elfutils-0.137/libdw -I ../../elfutils-0.137/libdw -I ../../elfutils-0.137/libelf/ -DX86_64 -Wall; local.c:8:23: error: libdw.h: No such file or directory local.c:9:19: error: dwarf.h: No such file or directory local.c:11:21: error: netdump.h: No such file or directory local.c:33: error: expected ‘)’ before ‘*’ token ... The extensions/sial.mk file is the only example in the upstream tree. Actually there are two alternatives: (1) as you are doing now, put your local.c and local.mk and whatever other files you need into an existing extensions subdirectory, or (2) build a standalone package that only requires the crash-devel subpackage. Alternative (2) allows you to create a standalone package that uses the crash-devel subpackage, which only consists of the "defs.h" file. Doing it that way you don't need the complete crash source tree. Your package is unique in that it currently needs "netdump.h" for the vmcore_data structure. I am not averse to moving that structure declaration into "defs.h" if you want to go that route. Check out the IBM crash-spu-commands-1.1-1.src.rpm package as an example of alternative (2): http://riksun.riken.go.jp/pub/pub/Linux/cern/updates/slc5X/SRPMS/crash-sp... In any case, that's easy enough to deal with in the future. I'd just continue working in the extensions subdirectory for now. That would be pid_to_context(). But more on that below... The only register sets are found in the per-cpu NT_PRSTATUS notes in the ELF header. They don't exist for the other non-active tasks, and in fact, the older netdump format only contains a single ELF NT_PRSTATUS for the crashing cpu task. Furthermore, if the kdump vmcore is compressed with "makedumpfile -c", then the resultant dumpfile's unique non-ELF header doesn't even contain those register sets. I don't know why that would be necessary. When your cmd_local() function is called without "-p <pid>", it should just default to the current context which would have been set with the prior "set -c <cpu>", "set <task>" or "set <pid>". For that matter, why do you even need "-p <pid>"? I'm not clear on why you wouldn't be using the current context all of the time? It appears that your mechanism will only work if the target task is an active task whose register set is contained in the ELF header. So when your command is called, it seems like it would simply need to first determine "can I handle this context?", and if not, just bail out. Dave