Re: [Crash-utility] [PATCH] debuginfo does not pick user_regs_struct on x86_64

> > Right -- over the years it has been "found" in some kernel > version's debuginfo data, but certainly not in all kernel > versions. (mostly not) > > But anyway, its potential non-existence has been worked > around such that the offset_table entries are not required. > > I did test it out on ~150 sample dumpfiles, and while it doesn't > break anything, it doesn't help either -- the "bt -a" output is > identical with or without the patch. The command "bt -a" can work fine without the patch now, because we have checked it in get_netdump_regs_x86_64(). We have a new hardware to do dump, and use makedumpfile to generate vmcore. Our hardware can work when the OS is out of controll(for example: dead loop). When we use crash to analyze the vmcore, bt can not work, because there is no panic task. We have provide the value of register in the vmcore(the format is elf_prstatus, it is same with normal kdump's vmcore). So I write the code to use the register from notes in the vmcore when we do not find panic task. So we should know these offsets. We can check it where we use, but I think it's better to check and init it in x86_64_init().

> > Did you actually have a situation where a backtrace failed > without it -- but then worked OK with your patch? > > And was there a reason you used "unsigned long long" declarations? > I understand they are the same, but the kernel uses "unsigned long". > Why the difference? Does this case exist: we build crash on x86 box and use it to analyze the vmcore which is generate in x86_64 box? If it does not exist, I think we should use "unsigend long", the same with the kernel.