From owner-freebsd-arch@FreeBSD.ORG Sat Feb 9 09:27:00 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6B83F343; Sat, 9 Feb 2013 09:27:00 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.freebsd.org (Postfix) with ESMTP id C817EFCE; Sat, 9 Feb 2013 09:26:58 +0000 (UTC) Received: from c211-30-173-106.carlnfd1.nsw.optusnet.com.au (c211-30-173-106.carlnfd1.nsw.optusnet.com.au [211.30.173.106]) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r199QlRN027425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Feb 2013 20:26:49 +1100 Date: Sat, 9 Feb 2013 20:26:47 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Christoph Mallon Subject: Re: Proposal: Unify printing the function name in panic messages() In-Reply-To: <51160E06.1070404@gmx.de> Message-ID: <20130209195417.C1753@besplex.bde.org> References: <51141E33.4080103@gmx.de> <511426B8.2070800@FreeBSD.org> <51160E06.1070404@gmx.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=RbTIkCRv c=1 sm=1 a=38QaZPNW7E4A:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=eOSutZEXEbgA:10 a=QiFWfQZKQqc9mlzFMg0A:9 a=CjuIK1q_8ugA:10 a=Q472suVMmv298HXA:21 a=5NugUVhWCmp0UsIz:21 a=TEtd8y5WR3g2ypngnwZWYw==:117 Cc: Kirk McKusick , Andriy Gapon , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2013 09:27:00 -0000 On Sat, 9 Feb 2013, Christoph Mallon wrote: > On 07.02.2013 23:12, Andriy Gapon wrote: >> on 07/02/2013 23:35 Christoph Mallon said the following: >>> panic("just a message"); >> >> This seems perfect. >> Panic without at least a stack trace or preferably a crash dump is practically >> useless in most cases. A stack trace already has all the function names. >> So a function name in a message seems to be redundant. > > This is nice in theory, but infeasible in practice. This is feasible in practice, and needs less churn. panic() can edit out duplicates. The callers can be changed at leisure. > More than half of the panic() calls include the correct function name in a way or another. If the function name is correct and is normally formatted as a literal followed by a colon and a space at the start of the message, then it is easy to detect and edit out. If the function name is __func__ and is normally formatted with "%s: " at the start of the format, then it is only a little harder to detect and equally easy to edit out. > I estimate, that another quarter show a wrong name. > It is hard to get this number mechanically, because, well, the names are wrong. If the name is wrong, then it is hard to detect the "duplication", either at runtime or by reading the code. > So most calls include the name (or try to). > Having no function name is a minority. > I plan to correct and unify this hotchpotch. > Also, if stack traces are disabled, you at least can reliably determine, where the panic came from. The name should still be printed in the panic message (unless you turn this off), using the same name lookup as stack tracing uses. If stack traces are disabled, then you normally shouldn't disable names in the panic message. Disabling them would normally not disable the deduplication, but deduplication could be controlled by another runtime option. > Finally, you can turn the names on and off with one central switch. A runtime switch works much better: - no code bloat for function names in all cases - no need to recompile to change the option - more control at runtime. Name lookup from the return address is broken for inline functions and for other optimizations like tail calls, but much more is broken for stack traces. Bruce