<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Dave Anderson wrote:
<blockquote cite="mid:46A66F19.9090301@redhat.com" type="cite"><br>
In the "heading-down-a-slippery-slope" department, I've hacked
<br>
up a version of crash that is capable of dealing with the
<br>
relocatable x86 FC7/upstream kernels, whose kernel symbol values
<br>
in the vmlinux file do not match up with their counterparts
<br>
when the kernel is actually loaded.
<br>
<br>
In the "vmlinux and /dev/crash do not match" FC7/upstream
<br>
scenario, the kernel gets compiled with:
<br>
</blockquote>
<br>
Why use /dev/crash instead of /proc/kcore? Wouldn't it be<br>
more symmetric to gdb and crash to rely on /proc/kcore<br>
shifting the reading/writing of the memory and for the<br>
kgdb stab to take care of it for live kernels? KDUMP <br>
would also use kcore compatible format. I tried crash<br>
on a /proc/kcore file and it didn't work. Seemed wrong<br>
to me. <br>
<br>
Feels like creeping <strong>schizophrenia.<br>
<br>
-piet<br>
</strong>
<blockquote cite="mid:46A66F19.9090301@redhat.com" type="cite"><br>
CONFIG_PHYSICAL_START=0x1000000 (16MB)
<br>
CONFIG_PHYSICAL_ALIGN=0x400000 (4MB)
<br>
<br>
In that case, the kernel symbols start at PAGE_OFFSET (c0000000)
<br>
plus the CONFIG_PHYSICAL_START value, or c1000000. However, despite
<br>
its name of "CONFIG_PHYSICAL_START", the kernel is actually loaded at
<br>
4MB physical, so the real "physical start" location looks to be
<br>
controlled by the CONFIG_PHYSICAL_ALIGN value. (Vivek, correct
<br>
me if I'm wrong...)
<br>
<br>
So, whereas the vmlinux file shows these symbol values:
<br>
<br>
$ nm -Bn vmlinux
<br>
...
<br>
c1000000 T _text
<br>
c1000000 T startup_32
<br>
c1001000 T startup_32_smp
<br>
c1001080 t checkCPUtype
<br>
c1001101 t is486
<br>
c1001108 t is386
<br>
c1001175 t check_x87
<br>
c10011a0 T setup_pda
<br>
c10011c2 t setup_idt
<br>
c10011df t rp_sidt
<br>
c1001262 t early_divide_err
<br>
c1001268 t early_illegal_opcode
<br>
c1001271 t early_protection_fault
<br>
c1001278 t early_page_fault
<br>
c100127f t early_fault
<br>
c10012a7 t hlt_loop
<br>
c10012ac t ignore_int
<br>
c10012f0 T _stext
<br>
c10012f0 t run_init_process
<br>
c10012f0 T stext
<br>
c1001304 t init_post
<br>
...
<br>
<br>
But when loaded into memory, they are all changed to reflect that
<br>
the kernel was loaded at at 4MB physical instead of 16MB:
<br>
<br>
$ cat /proc/kallsyms
<br>
c0400000 T _text
<br>
c0400000 T startup_32
<br>
c0401000 T startup_32_smp
<br>
c0401080 t checkCPUtype
<br>
c0401101 t is486
<br>
c0401108 t is386
<br>
c0401175 t check_x87
<br>
c04011a0 T setup_pda
<br>
c04011c2 t setup_idt
<br>
c04011df t rp_sidt
<br>
c0401262 t early_divide_err
<br>
c0401268 t early_illegal_opcode
<br>
c0401271 t early_protection_fault
<br>
c0401278 t early_page_fault
<br>
c040127f t early_fault
<br>
c04012a7 t hlt_loop
<br>
c04012ac t ignore_int
<br>
c04012f0 T _stext
<br>
c04012f0 t run_init_process
<br>
c04012f0 T stext
<br>
c0401304 t init_post
<br>
...
<br>
<br>
So in the case above, it amounts to a 12MB relocation from
<br>
from the compiled-in value to the loaded value. And so
<br>
if I:
<br>
<br>
(1) hack in the relocation value when reading/storing
<br>
the vmlinux symbols, and later on
<br>
(2) back-patch all of the "incorrect" symbols stored by gdb from
<br>
the vmlinux file -- in the same manner as when a System.map
<br>
file used,
<br>
<br>
then crash comes up fine, and everything seems to work OK.
<br>
(Although, as is the case when a System.map file is
<br>
used to back-patch gdb's notion of symbol values, line
<br>
numbers from gdb are unavailable)
<br>
<br>
Anyway, I can't find anything obvious in the vmlinux file
<br>
that indicates what the relocation value would be. On a
<br>
live system, the vmlinux symbols can be matched with
<br>
/proc/kallsyms if it exists. If /proc/kallsyms doesn't
<br>
exist, or if running against a dumpfile, the only option
<br>
I can think of is adding a crash command line "relocation"
<br>
argument.
<br>
<br>
On the other hand, it's preferable to configure the kernel
<br>
such that the virtual address for which it is compiled results
<br>
in "unity-mapped" kernel virtual addresses. That has always
<br>
been the case, where the kernel is compiled with a base virtual
<br>
address of c0100000 or c0400000, gets loaded at a base physical
<br>
address of 1MB or 4MB respectively, so that a virtual-to-
<br>
physical translation can be done by subtracting the c0000000
<br>
(PAGE_OFFSET) unity-map identifier. To make that happen with
<br>
the FC7/upstream kernels, the CONFIG_PHYSICAL_START address
<br>
needs to be equal to or less than the CONFIG_PHYSICAL_ALIGN
<br>
value. In other words, I've rebuilt with these two
<br>
combinations:
<br>
<br>
CONFIG_PHYSICAL_START=0x100000 (1MB)
<br>
CONFIG_PHYSICAL_ALIGN=0x400000 (4MB)
<br>
<br>
or
<br>
<br>
CONFIG_PHYSICAL_START=0x400000 (4MB)
<br>
CONFIG_PHYSICAL_ALIGN=0x400000 (4MB)
<br>
<br>
and in both cases the kernel gets compiled for c0400000 as
<br>
a base virtual address.
<br>
<br>
In any case, there is hope for handling such kernels.
<br>
<br>
Dave
<br>
<br>
<br>
--
<br>
Crash-utility mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Crash-utility@redhat.com">Crash-utility@redhat.com</a>
<br>
<a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/crash-utility">https://www.redhat.com/mailman/listinfo/crash-utility</a>
<br>
</blockquote>
<br>
</body>
</html>