Messages in this thread | | | Date | Mon, 16 May 2016 20:23:42 +0800 | From | Baoquan He <> | Subject | Re: [PATCH v2] kdump: Fix gdb macros work work with newer and 64-bit kernels |
| |
On 05/16/16 at 06:52am, Corey Minyard wrote: > On 05/16/2016 04:32 AM, Baoquan He wrote: > >On 05/10/16 at 07:30pm, minyard@acm.org wrote: > >>From: Corey Minyard <cminyard@mvista.com> > >> > >>Lots of little changes needed to be made to clean these up, remove the > >>four byte pointer assumption and traverse the pid queue properly. > >>Also consolidate the traceback code into a single function instead > >>of having three copies of it. > >> > >>Signed-off-by: Corey Minyard <cminyard@mvista.com> > >Hi Corey, > > > >Today I tried gdbmacro.txt and found dmesg doesn't work. I tested it > >on the latest 4.6.0 kernel. And I directly copy /proc/vmcore out > >and use gdb to open it by below command" > > > >gdb vmlinux /var/crash/vmcore --"gdbmacros.txt" > > > >All macro functions work well except of dmesg since code inside refer to > >the deprecated variable like "log_end" and "logged_chars". But these > >have been changed since this commit: > > > >commit 7ff9554bb578ba02166071d2d487b7fc7d860d62 > >Author: Kay Sievers <kay@vrfy.org> > >Date: Thu May 3 02:29:13 2012 +0200 > > > > printk: convert byte-buffer to variable-length record buffer > > > >So invoking dmesg will cause an error message printing out: > > > >(gdb) dmesg > >No symbol "log_end" in current context. > > Yes, I was actually aware of that, but that's a different issue and I > hadn't thought about it much.
Got it. Then fixes covered by this patch looks good. Ack it, thanks for this effort.
Acked-by: Baoquan He <bhe@redhat.com>
Thanks Baoquan
| |