----- "Mika Westerberg" <ext-mika.1.westerberg(a)nokia.com&gt; wrote: Let me first thank you guys for making the integration of this patch-set so simple, and for making the changes so non-intrusive. I did make a few minor changes/additions: In the spirit of avoiding "#ifdef <arch>" usage if at all possible, I renamed kdump_phys_base() to arm_kdump_phys_base() and removed the #ifdef ARM around it. I also removed the #ifdef ARM around the new entries in the offset_table and size_table, as there are already several arch-specific entries in there already. And I added those new offset_table and size_table entries to the dump_offset_table() output so that their values can be seen with "help -o". For minimal documentation, I added arm references to the README file. For building with the src.rpm, I added "arm" to the ExclusiveArch list in the crash.spec file. I fixed these warnings generated by "make warn": arm.c: In function ‘arm_dump_backtrace_entry’: arm.c:1160: warning: format ‘%d’ expects type ‘int’, but argument 6 has type ‘ulong’ arm.c:1166: warning: format ‘%d’ expects type ‘int’, but argument 7 has type ‘ulong’ arm.c: In function ‘arm_dump_irq’: arm.c:1424: warning: suggest parentheses around comparison in operand of ‘&’ arm.c:1490: warning: too many arguments for format arm.c:1357: warning: unused variable ‘tmp2’ arm.c: In function ‘arm_parse_cmdline_args’: arm.c:409: warning: ‘value’ may be used uninitialized in this function I modified arm_init() to capture any attempt to run an x86 binary built for ARM on a live x86 or x86_64 system to display a fatal error message indicating: "crash: compiled for the ARM architecture". As it was, it would fail with a nebulous "cannot resolve _stext" error. The only other suggestion I can make is to put something in either the top-level Makefile or in configure.c to catch/prevent a subsequent "make" command being entered after having first done the initial build with "make target=ARM". I found myself doing that constantly. Or vice-versa, for that matter. And if you really want to make the "other type" of binary, then there should be a message that kills the build attempt, and indicates that you'd have to do a "make clean" as well as removing the gdb subdirectory tree entirely. But that all can wait until after this first patch-set is released. So -- with the minor changes above -- consider it queued for the next release. And thanks again for making it so easy... Dave