David Howells wrote:
Russell King <rmk@xxxxxxxxxxxxxxxx> wrote:
Can you explain why you want this?
I'm wondering about the value of saving the registers; normally when a panic
occurs, it's because of a well defined reason, and not because something
went wrong in some CPU register; to put it another way, a panic() is a
more controlled exception than a BUG() or a bad pointer dereference.
+1.
I found in FS-Cache and CacheFiles that often the things I most wanted to know
when I had something of the form:
if (A == B)
BUG();
was a and b, so I made the following macro:
#define ASSERTCMP(X, OP, Y) \
do { \
if (unlikely(!((X) OP (Y)))) { \
printk(KERN_ERR "\n"); \
printk(KERN_ERR "AFS: Assertion failed\n"); \
printk(KERN_ERR "%lu " #OP " %lu is false\n", \
(unsigned long)(X), (unsigned long)(Y)); \
printk(KERN_ERR "0x%lx " #OP " 0x%lx is false\n", \
(unsigned long)(X), (unsigned long)(Y)); \
BUG(); \
} \
} while(0)
which I could then call like this:
ASSERTCMP(A, ==, B);
and if the assertion failed, it prints A and B explicitly. This is much
easier than trying to pick the values out of a register dump, especially as
the compiler may be free to clobber A or B immediately after testing them.
This is great if you'r in a development environment, and can focus on a
single, well
characterized case. Unfortunately, I'm staring at hundreds of thousands
of systems
in the field, all which which have a large number of panic() statements
for which this
approach has not been taken. So, I have no alternative but to pick the
value out of
a register dump.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
