From owner-freebsd-arch@FreeBSD.ORG Thu Sep 11 17:56:41 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FB6D106566B for ; Thu, 11 Sep 2008 17:56:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id CB4F88FC15 for ; Thu, 11 Sep 2008 17:56:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m8BHuVYO035323; Thu, 11 Sep 2008 13:56:32 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Matthew Dillon Date: Thu, 11 Sep 2008 10:28:59 -0400 User-Agent: KMail/1.9.7 References: <200809101531.54646.jhb@FreeBSD.org> <200809101806.38042.jhb@freebsd.org> <200809110006.m8B06vOU033199@apollo.backplane.com> In-Reply-To: <200809110006.m8B06vOU033199@apollo.backplane.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809111028.59610.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Thu, 11 Sep 2008 13:56:32 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8219/Thu Sep 11 11:02:39 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: arch@freebsd.org Subject: Re: PASSERT() - asserting for panics X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2008 17:56:41 -0000 On Wednesday 10 September 2008 08:06:57 pm Matthew Dillon wrote: > > :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); The problem is I want panics in unmodified code to be caught. For example, I want to write regression tests to make sure assertions on locking primivities fail when the state of the lock doesn't match what the assertion is requiring. I can do something fairly simple though that lets me do this: PANIC_TRY { stuff; } PANIC_CATCH { IGNORE_PANIC("this one is ok"); /* WITNESS can do different panics in foo_assert() sometimes */ IGNORE_PANIC("this one is too"); UNEXPECTED_PANIC(); } Without needing goto's. > 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. We use setjmp already if you get a trap in ddb so ddb doesn't crash. > 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. To catch unmodified panics, I have to have the longjmp in panic() itself, and I have the jmpbuf hung off of curthread. -- John Baldwin