----- Original Message ----- > > > > 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(). Interesting -- so you essentially have an alternative dumping method whose format simulates a kdump. > > > > 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. No, that cannot be done. You can build an x86 binary on an x86_64 machine with "make target=X86", but not the other way around. I'll revert them to "unsigned long" declarations, and queue the patch for crash-5.1.3. Thanks, Dave -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
