(2013/10/08 22:38), Dave Anderson wrote:
----- Original Message -----
(2013/10/07 22:21), Dave Anderson wrote:
----- 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.
Sorry, I don't understand why relocation size cannot be calculated when
CONFIG_PHYSICALSTART > CONFIG_PHYSICAL_ALIGN. Could you explain that?
I just meant that when CONFIG_PHYSICAL_START > CONFIG_PHYSICAL_ALIGN, the 32-bit x86 kernel
gets relocated (like the secondary kdump kernel), but that information is not readily available
from the vmlinux/vmcore pair.
My understanding on CONFIG_PHYSICAL_ALIGN was that starting address of kernel text area
is always rounded up to CONFIG_PHYSICAL_ALIGN, only. Your explanation would be part I don't
understand well. I'll reconsider it locally...
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?
It seems to me almost similar to what crash currently does even if we do relocation check.
The current check crash currently does is trial-and-error since there's no information
indicating given vmcore and vmlinuxcertainly match well.
For example, the process I imagine is:
1) try to match vmcore and vmlinux with no relocation. If fails, go to 2).
2) try to match vmcore and vmlinux with relocation.
The two steps include symbol table initialization so it might actually be difficult to
resume back from 2) to 1).
Also, if gap due to phys_base and gap due to relocation can happen at the same time,
calculating two values automatically might be futher complicated. So, it would be better
to add relocation value in VMCOREINFO. Then, what crash utility sholud do becomes very simple.
Yes please...
And while you're at it, the kernel's
VMCOREINFO_SYMBOL(phys_base);
is pretty much useless, at least w/respect to ELF vmcores, since we need to know its
value in order to translate the address. And I don't think that makedumpfile uses
it when it calculates the phys_base that it stores in compressed kdump headers. Why
not put its value instead of its address?
Yes, I've also noticed this fact. Anyway, I'll post a patch to improvement this phys_base
and a patch to export relocation information in VMCOREINFO.
--
Thanks.
HATAYAMA, Daisuke
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility