kernel 5.4.3, arm: crash: system.map and dump do not match! (with fix)

[mthenault]

Hi, I have a problem with kernel 5.4 on arm.
crash is invoked like this:
./crash vmlinux system.map dump

I get the following result:

kernel 5.4: DBG: WARNING: invalid linux_banner pointer: 756e694c
DBG: crash: system.map and dump do not match!

Here are my observations:

cat system.map | grep linux_banner
c0c00084 D linux_banner

kernel.c:

	if (!(sp = symbol_search("linux_banner")))  // 1. struct syment sp gets filled here
		error(FATAL, "linux_banner symbol does not exist?\n");
	else if ((sp->type == 'R') || (sp->type == 'r') ||
		 (machine_type("ARM") && sp->type == 'T') ||
		 (machine_type("ARM64")))
		linux_banner = symbol_value("linux_banner");   // 2. we don't enter here because sp->type == 'D'
	else                         
		get_symbol_data("linux_banner", sizeof(ulong), &linux_banner); // 3. This doesn't work and gives a wrong address		

With gdb debugging I can see that the struct syment is fine address-wise:

(gdb) print sp->type
$2 = 68 'D'
(gdb) print sp->name
$3 = 0xf73de297 "linux_banner"
(gdb) print sp->value
$4 = 3233808516 (note: c0c00084 hex)

sp->type is equal to 'D' this prevents us to enter the else if even though calling symbol_value("linux_banner"); would be fine:

ulong
symbol_value(char *symbol)
{
        struct syment *sp;

        if (!(sp = symbol_search(symbol))) // calls symbol_search again
                error(FATAL, "cannot resolve \"%s\"\n", symbol);

        return(sp->value);  // correct value (see gdb output)
}

I fixed this locally by adding sp->type == 'D' in the else if condition.

What does 'D' mean in struct syment type ? Is this a bug ? If yes I can submit a patch.

[bhupesh-sharma]

Hello,

On Thu, Sep 10, 2020 at 5:52 PM mthenault ***@***.***> wrote: Hi, I have a problem with kernel 5.4 on arm32. crash is invoked like this: ./crash vmlinux system.map dump I get the following result: kernel 5.4: DBG: WARNING: invalid linux_banner pointer: 756e694c DBG: crash: system.map and dump do not match! Here are my observations: cat system.map | grep linux_banner c0c00084 D linux_banner kernel.c: if (!(sp = symbol_search("linux_banner"))) // => struct syment sp gets filled here error(FATAL, "linux_banner symbol does not exist?\n"); else if ((sp->type == 'R') || (sp->type == 'r') || (machine_type("ARM") && sp->type == 'T') || (machine_type("ARM64"))) linux_banner = symbol_value("linux_banner"); // we don't enter here because sp->type == 'D' else get_symbol_data("linux_banner", sizeof(ulong), &linux_banner); // This doesn't work and gives a wrong address with gdb I can see that the struct syment is fine adress wise: (gdb) print sp->type $2 = 68 'D' (gdb) print sp->name $3 = 0xf73de297 "linux_banner" (gdb) print sp->value $4 = 3233808516 (note: c0c00084 hex) sp->type is equal to 'D' this prevents us to enter the first else if even though calling symbol_value("linux_banner"); would be fine: ulong symbol_value(char *symbol) { struct syment *sp; if (!(sp = symbol_search(symbol))) // calls symbol_search again error(FATAL, "cannot resolve \"%s\"\n", symbol); return(sp->value); // returns value which is correct (see gdb output) } I fixed this locally by adding sp->type == 'D' in the else if condition. *What does 'D' mean in struct syment type ? Is this a bug ?* If yes I can submit a patch.

This is very strange - normally you would get a 'R', 'r' or 'T' here instead of a 'D". For example of my arm64 machine it is a 'R': # cat /boot/System.map-5.9.0-rc3+ | grep linux_banner ffff800010a90140 R linux_banner I don't have an arm32 setup available with me right now, so I have requested one on loan, in the meanwhile can you please share the output of '#crash -d31 vmlinux system.mpa dump', so that we can see what linux_banner info (if any) is printed by the crash tool there. Thanks, Bhupesh

[mthenault]

ok, here is the output
output.txt

[k-hagio]

Thanks for your report.

What does 'D' mean in struct syment type ?

I think this description in the man page of nm command is it:

           "D"
           "d" The symbol is in the initialized data section.

Is this a bug ?

It would be depending on why its type is 'D' on your arm32 machine.
If it is due to an upstream kernel patch or a configuration and it can happen commonly,
then crash should support it.

@bhupesh-sharma Does your arm32 system have the same type 'D'?