----- Original Message -----(2013/10/03 22:47), Dave Anderson wrote:
----- Original Message -----(2013/10/02 18:13), HATAYAMA Daisuke wrote:(2013/10/02 16:48), Kees Cook wrote:
Thanks for detailed explanation. So, there's already a feature in crash utility
to address relocation!, though it's better for me to try them to check if it's
really applicable to this feature. My concern is whether --reloc works well
on x86_64 too, because relocation has never done on x86_64 ever, right?
Correct.
Another concern is that in case of relocation, users need to additional information
regarding runtime symbol information to crash utility. I want to avoid additional
process, automation is preferable if possible.
Right. As I mentioned in the case of 32-bit x86 dumpfiles, there is no automation
available when CONFIG_PHYSICAL_START is larger than CONFIG_PHYSICAL_ALIGN. The user
either has to be aware of their values in order to calculate the --reloc argument,
or has to capture a copy of the /proc/kallsyms file on the crashed system. Typically
users/distros using kdump changed their x86 configurations to avoid having to deal
with that.
I guess it's enough if there's runtime symbol addresses because we can get relocated
offset value by comparing it with the compile-time symbol address contained in
a given debuginfo file. Candidates for such symbols are the ones contained in
VMCOREINFO note containing some symbol values for makedumpfile to refer to mm-related
objects in kernel, which is always contained in vmcore generated by current kdump and
also vmcores converted by makedumpfile from it. How about this idea?
But how would that differ from using an incorrect (non-matching) vmlinux file?