- Aug 20, 2014
-
-
Michal Marek authored
The Makefiles call the respective interpreter explicitly, but this makes it easier to use the scripts manually. Signed-off-by:Michal Marek <mmarek@suse.cz>
-
- Jun 09, 2014
-
-
Masahiro Yamada authored
Signed-off-by:Masahiro Yamada <yamada.m@jp.panasonic.com>
-
- Feb 05, 2010
-
-
Hui Zhu authored
1. Fix a little format issue. 2. Check the return of "Getopt::Long::GetOptions". Output usage and exit if it get error. 3. Change $ARGV[$#ARGV] to $ARGV[0]. 4. Change the code which get $modulefile from modinfo. Replace the pipeline with `modinfo -F filename $module`. 4. Change usage from "Specify the module directory name" to "Specify the module filename". Signed-off-by:
Hui Zhu <teawater@gmail.com> Signed-off-by:
-
Hui Zhu authored
The markup_oops.pl have 3 troubles to support cross-compiler environment: 1. It use objdump directly. 2. It use modinfo to get the message of module. 3. It use hex function that cannot support 64-bit number in 32-bit arch. This patch add 3 options to markup_oops.pl: 1. -c CROSS_COMPILE Specify the prefix used for toolchain. 2. -m MODULE_DIRNAME Specify the module directory name. 3. Change hex function to Math::BigInt->from_hex. After this patch, parse the x8664 oops in x86, we can: cat amd64m | perl ~/kernel/tmp/m.pl -c /home/teawater/kernel/bin/x8664- -m ./e.ko vmlinux Thanks, Hui Signed-off-by:
WANG Cong <xiyou.wangcong@gmail.com> Signed-off-by:
-
- Feb 03, 2010
-
-
Hui Zhu authored
When I use markup_oops.pl parse a x8664 oops, I got: objdump: --start-address: bad number: NaN No matching code found This is because: main::(./m.pl:228): open(FILE, "objdump -dS --adjust-vma=$vmaoffset --start-address=$decodestart --stop-address=$decodestop $filename |") || die "Cannot start objdump"; DB<3> p $decodestart NaN This NaN is from: main::(./m.pl:176): my $decodestart = Math::BigInt->from_hex("0x$target") - Math::BigInt->from_hex("0x$func_offset"); DB<2> p $func_offset 0x175 There is already a "0x" in $func_offset, another 0x makes it a NaN. The $func_offset is from line: if ($line =~ /RIP: 0010:\[\<[0-9a-f]+\>\] \[\<[0-9a-f]+\>\] ([a-zA-Z0-9\_]+)\+(0x[0-9a-f]+)\/0x[a-f0-9]/) { $function = $1; $func_offset = $2; } I make a patch to change "(0x[0-9a-f]+)\/0x[a-f0-9]/)" to "0x([0-9a-f]+)\/0x[a-f0-9]/)". Signed-off-by:Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- Feb 02, 2010
-
-
Hui Zhu authored
I got a "No matching code found" when I use markup_oops.pl parse a error in a x86_64 module. cat e.c int init_module(void) { char *buf = 0; buf[0] = 3; return 0; } void cleanup_module(void) { //char *buf = 0; //buf[0] = 3; } MODULE_AUTHOR("Hui Zhu"); MODULE_LICENSE("GPL"); 0000000000000000 <init_module>: init_module(): /home/teawater/study/kernel/stack2core/example/e.c:10 0: c6 04 25 00 00 00 00 movb $0x3,0x0 7: 03 /home/teawater/study/kernel/stack2core/example/e.c:13 8: 31 c0 xor %eax,%eax a: c3 retq b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) 0000000000000010 <cleanup_module>: cleanup_module(): /home/teawater/study/kernel/stack2core/example/e.c:20 10: f3 c3 repz retq 12: 90 nop 13: 90 nop Disassembly of section .modinfo: This is because the faulting instruction "movb $0x3,0x0" is the first line of the range. In the markup_oops.pl: main::(./scripts/markup_oops.pl:245): 245: if (InRange($1, $target)) { DB<2> p $line ffffffffa001b000: c6 04 25 00 00 00 00 movb $0x3,0x0 DB<3> p $counter 0 It just set $center in next loop. So it cannot get the $center. And even if $center is set to the right value 0. if ($center == 0) { print "No matching code found \n"; exit; } The first line $center will be 0, so I change the default value to -1. Signed-off-by:
-
- Jan 16, 2010
-
-
Hui Zhu authored
When I try to use markup_oops.pl in x86, I always get: cat 1 | perl markup_oops.pl ./vmlinux objdump: --start-address: bad number: NaN No matching code found This is because in line: if ($line =~ /EIP is at ([a-zA-Z0-9\_]+)\+0x([0-9a-f]+)\/[a-f0-9]/) { $function = $1; $func_offset = $2; } $func_offset will get a number like "0x2" But in follow code: my $decodestart = Math::BigInt->from_hex("0x$target") - Math::BigInt->from_hex("0x$func_offset"); It add other ox to ox2. Then this value will be set to NaN. So I made a small patch to fix it. Signed-off-by:Arjan van de Ven <arjan@linux.intel.com> Signed-off-by:
-
- Sep 20, 2009
-
-
Ozan Çaglayan authored
When EIP is at a module having an underscore in its name, the current code fails to find it because the module filenames has '-' instead of '_'. Use modinfo for a better path finding. Signed-off-by:
Ozan Çaglayan <ozan@pardus.org.tr> Acked-by:
Sam Ravnborg <sam@ravnborg.org>
-
- Jul 30, 2009
-
-
Matthew Wilcox authored
A 32-bit perl can't handle 64-bit addresses without using the BigInt package. Signed-off-by:
Matthew Wilcox <willy@linux.intel.com> Acked-by:
-
- Feb 15, 2009
-
-
Arjan van de Ven authored
Signed-off-by:
-
Arjan van de Ven authored
An oops dump also contains the register values. This patch parses these for (32 bit) x86, and then annotates the disassembly with these values; this helps in analysis of the oops by the developer, for example, NULL pointer or other pointer bugs show up clearly this way. Signed-off-by:
-
- Jan 13, 2009
-
-
Arjan van de Ven authored
There has been some light flamewar on lkml about decoding oopses in modules (as part of the crashdump flamewar). Now this isn't rocket science, just the markup_oops.pl script cheaped out and didn't handle modules. But really; a flamewar all about that?? What happened to C++ in the kernel or reading files from inside the kernel? This patch adds module support to markup_oops.pl; it's not the most pretty perl but it works for my testcases... Signed-off-by:
-
- Jan 06, 2009
-
-
Arjan van de Ven authored
We're struggling all the time to figure out where the code came from that oopsed.. The script below (a adaption from a script used by kerneloops.org) can help developers quite a bit, at least for non-module cases. It works and looks like this: [/home/arjan/linux]$ dmesg | perl scripts/markup_oops.pl vmlinux { struct agp_memory *memory; memory = agp_allocate_memory(agp_bridge, pg_count, type); c055c10f: 89 c2 mov %eax,%edx if (memory == NULL) c055c111: 74 19 je c055c12c <agp_allocate_memory_wrap+0x30> /* This function must only be called when current_controller != NULL */ static void agp_insert_into_pool(struct agp_memory * temp) { struct agp_memory *prev; prev = agp_fe.current_controller->pool; c055c113: a1 ec dc 8f c0 mov 0xc08fdcec,%eax *c055c118: 8b 40 10 mov 0x10(%eax),%eax <----- faulting instruction if (prev != NULL) { c055c11b: 85 c0 test %eax,%eax c055c11d: 74 05 je c055c124 <agp_allocate_memory_wrap+0x28> prev->prev = temp; c055c11f: 89 50 04 mov %edx,0x4(%eax) temp->next = prev; c055c122: 89 02 mov %eax,(%edx) } agp_fe.current_controller->pool = temp; c055c124: a1 ec dc 8f c0 mov 0xc08fdcec,%eax c055c129: 89 50 10 mov %edx,0x10(%eax) if (memory == NULL) return NULL; agp_insert_into_pool(memory); so in this case, we faulted while dereferencing agp_fe.current_controller pointer, and we get to see exactly which function and line it affects... Personally I find this very useful, and I can see value for having this script in the kernel for more-than-just-me to use. Caveats: * It only works for oopses not-in-modules * It only works nicely for kernels compiled with CONFIG_DEBUG_INFO * It's not very fast. * It only works on x86 Signed-off-by:
-
