Amit Kale wrote:
Is vmlinux a relocatable object file in FC7? If it is, we can make gdb load it at a different address easily by using "add-symbol-file" command with offsets.
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.
Unfortunately AFAIK core files only contain data sections and there is no way of specifying relocated code section addresses.
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.
Perhaps we can create a /proc/maps file for kernel just like /proc/self/maps for processes.
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 -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
