In the "heading-down-a-slippery-slope" department, I've hacked
up a version of crash that is capable of dealing with the
relocatable x86 FC7/upstream kernels, whose kernel symbol values
in the vmlinux file do not match up with their counterparts
when the kernel is actually loaded.

In the "vmlinux and /dev/crash do not match" FC7/upstream
scenario, the kernel gets compiled with:

  CONFIG_PHYSICAL_START=0x1000000   (16MB)
  CONFIG_PHYSICAL_ALIGN=0x400000    (4MB)

In that case, the kernel symbols start at PAGE_OFFSET (c0000000)
plus the CONFIG_PHYSICAL_START value, or c1000000.  However, despite
its name of "CONFIG_PHYSICAL_START", the kernel is actually loaded at
4MB physical, so the real "physical start" location looks to be
controlled by the CONFIG_PHYSICAL_ALIGN value.  (Vivek, correct
me if I'm wrong...)

So, whereas the vmlinux file shows these symbol values:

  $ nm -Bn vmlinux
  ...
  c1000000 T _text
  c1000000 T startup_32
  c1001000 T startup_32_smp
  c1001080 t checkCPUtype
  c1001101 t is486
  c1001108 t is386
  c1001175 t check_x87
  c10011a0 T setup_pda
  c10011c2 t setup_idt
  c10011df t rp_sidt
  c1001262 t early_divide_err
  c1001268 t early_illegal_opcode
  c1001271 t early_protection_fault
  c1001278 t early_page_fault
  c100127f t early_fault
  c10012a7 t hlt_loop
  c10012ac t ignore_int
  c10012f0 T _stext
  c10012f0 t run_init_process
  c10012f0 T stext
  c1001304 t init_post
  ...

But when loaded into memory, they are all changed to reflect that
the kernel was loaded at at 4MB physical instead of 16MB:

  $ cat /proc/kallsyms
  c0400000 T _text
  c0400000 T startup_32
  c0401000 T startup_32_smp
  c0401080 t checkCPUtype
  c0401101 t is486
  c0401108 t is386
  c0401175 t check_x87
  c04011a0 T setup_pda
  c04011c2 t setup_idt
  c04011df t rp_sidt
  c0401262 t early_divide_err
  c0401268 t early_illegal_opcode
  c0401271 t early_protection_fault
  c0401278 t early_page_fault
  c040127f t early_fault
  c04012a7 t hlt_loop
  c04012ac t ignore_int
  c04012f0 T _stext
  c04012f0 t run_init_process
  c04012f0 T stext
  c0401304 t init_post
  ...

So in the case above, it amounts to a 12MB relocation from
from the compiled-in value to the loaded value.  And so
if I:

 (1) hack in the relocation value when reading/storing
     the vmlinux symbols, and later on
 (2) back-patch all of the "incorrect" symbols stored by gdb from
     the vmlinux file -- in the same manner as when a System.map
     file used,

then crash comes up fine, and everything seems to work OK.
(Although, as is the case when a System.map file is
used to back-patch gdb's notion of symbol values, line
numbers from gdb are unavailable)

Anyway, I can't find anything obvious in the vmlinux file
that indicates what the relocation value would be.  On a
live system, the vmlinux symbols can be matched with
/proc/kallsyms if it exists.  If /proc/kallsyms doesn't
exist, or if running against a dumpfile, the only option
I can think of is adding a crash command line "relocation"
argument.

On the other hand, it's preferable to configure the kernel
such that the virtual address for which it is compiled results
in "unity-mapped" kernel virtual addresses.  That has always
been the case, where the kernel is compiled with a base virtual
address of c0100000 or c0400000, gets loaded at a base physical
address of 1MB or 4MB respectively, so that a virtual-to-
physical translation can be done by subtracting the c0000000
(PAGE_OFFSET) unity-map identifier.  To make that happen with
the FC7/upstream kernels, the CONFIG_PHYSICAL_START address
needs to be equal to or less than the CONFIG_PHYSICAL_ALIGN
value.  In other words, I've rebuilt with these two
combinations:

  CONFIG_PHYSICAL_START=0x100000    (1MB)
  CONFIG_PHYSICAL_ALIGN=0x400000    (4MB)

or

  CONFIG_PHYSICAL_START=0x400000    (4MB)
  CONFIG_PHYSICAL_ALIGN=0x400000    (4MB)

and in both cases the kernel gets compiled for c0400000 as
a base virtual address.

In any case, there is hope for handling such kernels.

Dave


--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility