PASSERT() - asserting for panics
Matthew Dillon
dillon at apollo.backplane.com
Thu Sep 11 00:06:57 UTC 2008
:I think part of the pollution is that what I really want to do is treat a
:panic like an exception that I can catch. I could probably make that idiom
:work with two macros so your code can be:
:
: PANIC_TRY {
: /* do stuff */
: } PANIC_CATCH("foo");
:
:That could potentially work with some evil goto's that jumped between the
:macros (i.e. have the setjmp() in PANIC_CATCH and PANIC_TRY goto's down to
:--
:John Baldwin
Hmm. Almost java-like, where an exception pops back through subroutine
levels until it finds a match. That kind of functionality would be a
real mess in C. A limited form would be possible, something like this:
#define PANIC_CATCH(label) \ (...)
static jmpbuf label # _jmpbuf
if (0) {
for (;;) {
longjmp(&label # _jmpbuf);
label:
#define PANIC_RETRY }}
#define PANIC_PANIC panic(...); }}
#define PASSERT(label, cond) \ (...)
if (__predict_false(!(cond))) {
setjmp (&label # _jmpbuf);
goto label;
}
PANIC_CATCH(badthings) {
...
PANIC_RETRY;
}
PANIC_CATCH(badthings) {
...
PANIC_PANIC;
}
PASSERT(badthings, x == 1);
Which would allow you some control over the context plus allow multiple
PASSERT's with the same label. But, OMG I don't know about doing
setjmp/longjmp in the kernel. I don't think it would be worth it.
Theoretically one could cross procedural boundaries with the longjmp,
and place the jmpbuf in a DATASET and have the kernel glue the longjmp
address. That would be a candidate for the C obfuscation contest
though.
-Matt
Matthew Dillon
<dillon at backplane.com>
More information about the freebsd-arch
mailing list