From owner-freebsd-arch@FreeBSD.ORG Wed Feb 13 03:59:57 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 332C4F51 for ; Wed, 13 Feb 2013 03:59:57 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) by mx1.freebsd.org (Postfix) with ESMTP id F001090E for ; Wed, 13 Feb 2013 03:59:56 +0000 (UTC) Received: by mail-oa0-f42.google.com with SMTP id i18so883154oag.1 for ; Tue, 12 Feb 2013 19:59:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=gB8AHNJ8m1HK0jglhuaY8G7fPmNks7M3494Rs9qEt5Y=; b=lUwrLxs+v8OmU/hd9mSr7JAnz5et/XoHeUrkJvQr/1aENLWr8CvIAUrS02G54GrCfU rSGMsOxpqFvQE1IqV75HJydcjL9qV8xMkcc8NDhBeMF3gzp7pC4V3BPfSHCQ9Asvr5cK Mf96uq0r9CmlkteuPNtyM+2kbSWTDNXFf53E1t2vJ4XSQ2A+gPvtLR8EYAb0UavamR5g iwkTJQ620Sp/WRt59xLZecnzkaqHK2YkiX/rIA5gnJCN3mFTxu2In9q0EbVZs/S+Ppsz KCSwLaMnsZyamKOP5yQ+o6sGtbOPegyBn7iokVFMF18NIgYKxkv7r3JA6yQZaHFYUC5/ ccwQ== X-Received: by 10.182.144.40 with SMTP id sj8mr15213949obb.82.1360727990240; Tue, 12 Feb 2013 19:59:50 -0800 (PST) Received: from 53.imp.bsdimp.com ([209.117.142.2]) by mx.google.com with ESMTPS id w10sm57100439oeg.2.2013.02.12.19.59.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 19:59:49 -0800 (PST) Sender: Warner Losh Subject: Re: Proposal: Unify printing the function name in panic messages() Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Warner Losh In-Reply-To: Date: Tue, 12 Feb 2013 20:59:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: 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> To: Mehmet Erol Sanliturk X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnfUpoWpX8LcCJ4dNiibEwNfuurb0445uaUPTQwXwZxg6USpjO9/k6N9+Mz9Xe8QvyyAtZw Cc: Kirk McKusick , =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , 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 03:59:57 -0000 On Feb 12, 2013, at 6:56 PM, Mehmet Erol Sanliturk wrote: > On Tue, Feb 12, 2013 at 5:22 PM, Dag-Erling Sm=F8rgrav = wrote: >=20 >> Mehmet Erol Sanliturk writes: >>> My intention was to say a message like the following : >>>=20 >>> 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 > . >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >>> In "Witness" mode , a list is displayed by hexadecimal addresses . >>=20 >> and that's all you're going to get... >>=20 >> 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. >>=20 >> DES >> -- >> Dag-Erling Sm=F8rgrav - des@des.no >>=20 >=20 >=20 > 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 : You are wrong. > 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 . Uberslow. The normal way of just keeping tables of mappings from PC to = line number doesn't slow things down at all. This would bloat the code = and slow things down. > When code size is critical , during compilation , even this feature = may be > disabled . >=20 > Especially for server usage and desktop usage , memory is not very = critical > , but program quality maintenance is much more important . >=20 > Such a feature will eliminate debug runs for all errors which can be > trapped during run time . It is easier to just do minidumps... Warner >=20 > Thank you very much . >=20 > Mehmet Erol Sanliturk > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to = "freebsd-arch-unsubscribe@freebsd.org"