(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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
