From owner-freebsd-arch@FreeBSD.ORG Wed Feb 13 01:57:09 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 9C7CDF4E; Wed, 13 Feb 2013 01:57:09 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-vb0-f45.google.com (mail-vb0-f45.google.com [209.85.212.45]) by mx1.freebsd.org (Postfix) with ESMTP id 4AE7C20F; Wed, 13 Feb 2013 01:57:08 +0000 (UTC) Received: by mail-vb0-f45.google.com with SMTP id p1so477951vbi.32 for ; Tue, 12 Feb 2013 17:57:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=YWy3n6Rtq5h0YhvfcAiksCdtqvSwgZAJkvlPgpMhAIs=; b=0AJUFhWfAMXwvo9JFBVhgf+lYMcqPjSZRZo5NoDglgrdLG9VSfeMaQC5Av/NX/sNkf xi3O7Bc2EQAngEvK4eascbjTZQJUm4u9eNlAxhqt+BfhihpF2d4whYV6xh7dRTB8Yy2N r7ea1LTeDo6Gj7IIKXJZb/+5dTPaWZPhgXQa4jADhHc3PTFIt8B37SCYh5CwMxBCpYtJ t6pvxhk7Y2Jj1+XYP56GFKUfch+ZjpJ3fu7tLMscdHS87wmeYm3VOu0Cmi0RtQBPi19r 2AjMSFy/4xCTy3QLsPD5CLrbhZTOObFyf+B/aINtmLunVEvzdNXZhSKdqKtrhpoJQ/PE 2eFw== MIME-Version: 1.0 X-Received: by 10.220.154.148 with SMTP id o20mr27371134vcw.54.1360720617439; Tue, 12 Feb 2013 17:56:57 -0800 (PST) Received: by 10.58.170.36 with HTTP; Tue, 12 Feb 2013 17:56:57 -0800 (PST) In-Reply-To: <86vc9xf1nk.fsf@ds4.des.no> References: <51141E33.4080103@gmx.de> <511426B8.2070800@FreeBSD.org> <51160E06.1070404@gmx.de> <5116121E.1010601@FreeBSD.org> <86fw11homa.fsf@ds4.des.no> <86vc9xf1nk.fsf@ds4.des.no> Date: Tue, 12 Feb 2013 17:56:57 -0800 Message-ID: Subject: Re: Proposal: Unify printing the function name in panic messages() From: Mehmet Erol Sanliturk To: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Kirk McKusick , Christoph Mallon , 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: Wed, 13 Feb 2013 01:57:09 -0000 On Tue, Feb 12, 2013 at 5:22 PM, Dag-Erling Sm=C3=B8rgrav wrot= e: > Mehmet Erol Sanliturk writes: > > My intention was to say a message like the following : > > > > In line < number > in routine < name > the error < name of error > has > > occurred > > called from line < number > of routine < name > , > > . > > . > > . > > called from line < number > of routine < name > . > > Keeping track of file names and line numbers for the entire kernel > require huge amounts of space, both on disk and in memory. For 9.1 > amd64, GENERIC + all modules weigh in at 62 MB, while the debugging > symbols (file names, line numbers and variable names) add 267 MB. > > Even counting only what's actually in use on a typical machine, like the > one I'm typing on right now, we get 18 MB of code + 80 MB of symbols. > > Don't forget that we need debugging symbols for every single line of > code, not just those that call panic(), because a) we want to unwind the > stack from the point where panic() was called and b) pretty much any > non-trivial C statement can potentially trigger a panic due to a bad > pointer or array index, a smashed stack, or any number of reasons. > > > In "Witness" mode , a list is displayed by hexadecimal addresses . > > and that's all you're going to get... > > although when an actual panic occurs, you get a core dump which you can > later examine with a debugger, which will give you far more information > than a simple stack trace. > > DES > -- > Dag-Erling Sm=C3=B8rgrav - des@des.no > My suggestion is ONLY to maintain a CALL stack , not any more . I think , only call stack maintenance will not require a large code size : Before call : push line number and routine name to call stack . Inside routine : On error call a routine to display call stack . After call : pop line number and routine name from call stack . When code size is critical , during compilation , even this feature may be disabled . Especially for server usage and desktop usage , memory is not very critical , but program quality maintenance is much more important . Such a feature will eliminate debug runs for all errors which can be trapped during run time . Thank you very much . Mehmet Erol Sanliturk