Amit Kale wrote: It is, as well as in RHEL5 for that matter. But until these kernels, the typical kernel configuration has always created kernel symbols that were unity-mapped. (at least for the primary kernel -- we don't care about supporting crash running on the secondary kdump kernel). The embedded gdb module inside of crash is invoked essentially as "gdb vmlinux". The "add-symbol-file" mechanics are currently used for loading kernel module objects, but I've never even considered using it on the same file. Interesting concept though, doing it on the vmlinux file itself a "second" time, but using a base address. I'm certainly not sure how that would work. The good news is that there's always been the capability in crash to use a non-matching vmlinux, but then override the symbol values in the vmlinux by adding the System.map file from the "real" kernel as a command line argument. The override is done early on by back-patching all of the symbols that gdb read from the non-matching vmlinux. Unfortunately the System.map file for these new kernels also has the "wrong" symbol values, since they are just pulled from the vmlinux file. I didn't notice until yesterday that /proc/kallsyms contains the "resolved" symbol values. So with some additional hackery, the same back-patching concept can be used; but I don't see how to do it "automatically", except for live systems that have /proc/kallsyms. Are you still talking about the vmlinux file or the kdump vmcore? The core files aren't a problem for crash, since it only pulls out physical memory information from the PT_LOAD segments. And the gdb module inside of crash doesn't know anything about core files -- it just knows that it was invoked as "gdb vmlinux", regardless whether crash itself is running against a dumpfile or a live system. Whatever -- although that won't help when running crash on dumpfiles on systems other than the host where the crash took place, right? Like I said, there may be something in the vmlinux file, but I couldn't find anything obvious. Dave