From owner-freebsd-arch@FreeBSD.ORG Wed Feb 13 04:22:53 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 E5453426; Wed, 13 Feb 2013 04:22:53 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) by mx1.freebsd.org (Postfix) with ESMTP id 5E6C79C1; Wed, 13 Feb 2013 04:22:52 +0000 (UTC) Received: by mail-ve0-f173.google.com with SMTP id oz10so748660veb.4 for ; Tue, 12 Feb 2013 20:22:52 -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=eMa7lG+UlfGAkr5UOIBeq2D7qCtfo+8MXrY3vqftV9Y=; b=KKgw1o0ZA1dAZv/efA61qqwFCsIXOIu87Tv7FQJrghdtwG7aRxcHcr3o395AMOomJa +GDlxrvQ6iSPVAiZ1SFrFp+qw5+n5+YK+3rM/7PQowRjunBod7vNutL8LWlgPgeJI5ox D7PiZYuLodUvT1Va3nPDmlpP3Z3vprfWdgCMOhJXq+eQkhwxvmdKNGmSuz0z3Btuy8xM UMWqvYIN8rkYIVDSACLIYytfLVthL8TI5iEMitq3j7tiSvXrWUKEj8yP4F8WeZzyqrvw PrN2Xqc5mNij/I2ROQAYJXcERze4/k3Zrl0ufcYiht237C8W2mNcLOq6AHgEbrQcLmhK zvSg== MIME-Version: 1.0 X-Received: by 10.52.98.196 with SMTP id ek4mr24398497vdb.16.1360729372184; Tue, 12 Feb 2013 20:22:52 -0800 (PST) Received: by 10.58.170.36 with HTTP; Tue, 12 Feb 2013 20:22:52 -0800 (PST) In-Reply-To: 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 20:22:52 -0800 Message-ID: Subject: Re: Proposal: Unify printing the function name in panic messages() From: Mehmet Erol Sanliturk To: Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Kirk McKusick , =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= , 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 04:22:54 -0000 On Tue, Feb 12, 2013 at 7:59 PM, Warner Losh wrote: > > On Feb 12, 2013, at 6:56 PM, Mehmet Erol Sanliturk wrote: > > > On Tue, Feb 12, 2013 at 5:22 PM, Dag-Erling Sm=C3=B8rgrav = wrote: > > > >> 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 > ha= s > >>> 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 t= he > >> 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 t= he > >> 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 ca= n > >> later examine with a debugger, which will give you far more informatio= n > >> 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 : > > You are wrong. > Program development and maintenance costs ( programmer life and cost , debugging times , etc. ) , are much higher than importance of code size . In the present servers and desktops , nearly it is not possible to have memory sizes measured by less than 1000 mega bytes . For the rare cases , disabling the feature may be used . > > > 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 . > The above steps will be generated by the compiler . They will not be existent in written source code . Machine code bloating is not visible to the user . > > 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 an= d > slow things down. > Since compilation of such statements will be generated based on a given flag , for critical programs it may be disabled ( not generated ) or such programs may be compiled as this feature enabled and executed for testing . > > > 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 . > > It is easier to just do minidumps... > > Warner > > > > > Thank you very much . > > > > Mehmet Erol Sanliturk > > >