I'm resending this to fastboot after 'fixing' my MTA (SPF ate my previous mail).
---------- Forwarded message ---------- Date: Thu, 12 Oct 2006 00:20:01 +0200 (CEST) From: Jean-Marc Saffroy <[EMAIL PROTECTED]> To: [email protected] Subject: [announce] kdump2gdb 0.2 [bcc to [email protected], which is moderated for non-members] Hello folks, I have released kdump2gdb 0.2, a small tool that converts a kdump core to an ELF core that can be used with gdb. It now enables kernel-level backtracing of all processes from within gdb. Download it from here: http://jeanmarc.saffroy.free.fr/kdump2gdb/ Each process is seen as a thread, so you can use gdb's internal thread-related commands (which are much faster and richer than scripts): "info threads" to list them, "thread <NN>" to switch to any thread (no VMM context switch here), "bt" and "bt full", "up" and "down", as with a userland multithreaded core file. Due to optimizations (?), the stack frames decoded by gdb can be unaccurate, and should be taken with a grain of salt; I suspect setting CONFIG_STACK_UNWIND could yield better results. Below is the README. Feedback is welcome! Cheers, -- [EMAIL PROTECTED] kdump2gdb --------- The kdump2gdb script converts a kdump core file (which is essentially an ELF core) into a slightly different ELF core that can be directly used with gdb. It also produces a gdb script that loads the required kernel modules. Features: - completely automated: run kdump2gdb, then start gdb on your new core file, load modules, and enjoy! - the power of gdb to explore stack frames with full debug infos on all tasks Limitations: - currently limited to x86-64; but support for other arches should not be difficult to add - gdb scripting is *slow*! But a patch that improves this is already available, and I suspect there could be more in the near future. Sample session -------------- Below is an example of how I use kdump2gdb (from the tarball). As you can see, even on a 2GHz Athlon box with a patched gdb, it takes several minutes to complete. $ cd kdump2gdb-0.2 $ make gcc -Wall -g -lelf kdumpfix.c -o kdumpfix $ time ./kdump2gdb -k /var/dump/dump-2006-09-21_11\:15\:21 \ -d ~/kernel/build-2.6.18 -o /tmp/core -g modload Restoring low identity-mapped areas... Gathering vmalloc-mapped areas... warning: shared library handler failed to enable breakpoint Gathering thread data... warning: shared library handler failed to enable breakpoint Restoring vmalloc-mapped areas... Preparing gdb script to map modules... warning: shared library handler failed to enable breakpoint All done. Now you can do: $ gdb /home/saffroy/kernel/build-2.6.18/vmlinux /tmp/core (gdb) source modload (gdb) bt real 7m42.250s user 6m15.658s sys 0m6.520s (The warnings are produced by gdb, they are harmless.) Gdb patches ----------- I use gdb 6.5, and encountered the following problems: - gdb crashes in realloc on add-symbol-file: the fix is here: http://sources.redhat.com/ml/gdb-patches/2006-10/msg00056.html - gdb scripts are sooooooooooo sloooooow: a significant improvement is observed with the patch mentioned here: http://sources.redhat.com/ml/gdb/2006-10/msg00023.html You should edit the kdump2gdb script to use a specific gdb binary if needed. Licensing --------- This program is free software, distributed under the terms of the GNU General Public License version 2. Contact ------- Jean-Marc Saffroy <[EMAIL PROTECTED]> _______________________________________________ fastboot mailing list [email protected] https://lists.osdl.org/mailman/listinfo/fastboot
