[Crash-utility] - creeping schizophrenia?
Piet Delaney
pdelaney at bluelane.com
Tue Jul 24 23:40:36 UTC 2007
Dave Anderson wrote:
>
> 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:
Why use /dev/crash instead of /proc/kcore? Wouldn't it be
more symmetric to gdb and crash to rely on /proc/kcore
shifting the reading/writing of the memory and for the
kgdb stab to take care of it for live kernels? KDUMP
would also use kcore compatible format. I tried crash
on a /proc/kcore file and it didn't work. Seemed wrong
to me.
Feels like creeping *schizophrenia.
-piet
*
>
> 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 at redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20070724/ad15a46f/attachment.htm>
More information about the Crash-utility
mailing list