summaryrefslogtreecommitdiffstats
path: root/scripts/markup_oops.pl
Commit message (Collapse)AuthorAgeFilesLines
* markup_oops.pl: minor fixesHui Zhu2010-02-051-5/+5
| | | | | | | | | | | | | | 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: Michal Marek <mmarek@suse.cz>
* markup_oops.pl: add options to improve cross-sompilation environmentsHui Zhu2010-02-051-13/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Hui Zhu <teawater@gmail.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: ozan@pardus.org.tr Cc: Matthew Wilcox <willy@linux.intel.com> Acked-by: WANG Cong <xiyou.wangcong@gmail.com> Signed-off-by: Michal Marek <mmarek@suse.cz>
* markup_oops.pl: fix for faulting instruction in the first line of a rangeHui Zhu2010-02-021-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Hui Zhu <teawater@gmail.com> Signed-off-by: Michal Marek <mmarek@suse.cz>
* markup_oops.pl: fix error with x86Hui Zhu2010-01-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Hui Zhu <teawater@gmail.com> Acked-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* markup_oops: use modinfo to avoid confusion with underscored module namesOzan Çaglayan2009-09-201-4/+1
| | | | | | | | | | | | 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: WANG Cong <xiyou.wangcong@gmail.com> Cc: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
* markup_oops: fix it with 32-bit userspace on a 64-bit kernelMatthew Wilcox2009-07-291-2/+3
| | | | | | | | | | 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: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* scripts: add x86 64 bit support to the markup_oops.pl scriptArjan van de Ven2009-02-151-4/+55
| | | | | | Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
* scripts: add x86 register parser to markup_oops.plArjan van de Ven2009-02-151-6/+100
| | | | | | | | | | | | | 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: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
* script: improve markup_oops.pl to also decode oopses in modulesArjan van de Ven2009-01-121-9/+50
| | | | | | | | | | | | | | | | 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: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* scripts: script from kerneloops.org to pretty print oops dumpsArjan van de Ven2009-01-061-0/+162
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: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
OpenPOWER on IntegriCloud