[Crash-utility] [PATCH v2 0/6] crash utility - add ARM support

Mika Westerberg ext-mika.1.westerberg at nokia.com
Fri Aug 27 05:59:11 UTC 2010


On Thu, Aug 26, 2010 at 10:49:31PM +0200, ext Dave Anderson wrote:
> 
> 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

Argh!

Looks like I forgot to compile the latest patch set with warnings enabled :(
Thanks for fixing them and sorry for any inconvenience.

> 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.

Yeah, it is better to have some useful error message instead.

> 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.

OK.

> So -- with the minor changes above -- consider it queued for the next release.

Thanks!

Regards,
MW




More information about the Crash-utility mailing list