Date: Tue, 12 Feb 2013 20:22:52 -0800 From: Mehmet Erol Sanliturk <m.e.sanliturk@gmail.com> To: Warner Losh <imp@bsdimp.com> Cc: Kirk McKusick <mckusick@mckusick.com>, =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= <des@des.no>, Christoph Mallon <christoph.mallon@gmx.de>, Andriy Gapon <avg@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: Proposal: Unify printing the function name in panic messages() Message-ID: <CAOgwaMuZ4smc3%2BDR64-b9-yXwODA-BoHTBtBOB0OvEaRUcTbqg@mail.gmail.com> In-Reply-To: <E08E39A9-69E5-4E0C-85E1-0207A3E8AC7E@bsdimp.com> References: <51141E33.4080103@gmx.de> <511426B8.2070800@FreeBSD.org> <51160E06.1070404@gmx.de> <5116121E.1010601@FreeBSD.org> <CAOgwaMutXeb8EcCAAG7dKh%2Bci_o0Wy8xyYFbaYkigcduC=wjuA@mail.gmail.com> <86fw11homa.fsf@ds4.des.no> <CAOgwaMsM1iSr1fkbQY6VVLCX8oguQv0BYvj7CnJjVscF%2Bgd23g@mail.gmail.com> <86vc9xf1nk.fsf@ds4.des.no> <CAOgwaMvF%2BJ-ZQ3Bg0ZLVLv-7st0U7T%2BS6Vpd_Eubj_v83D7r%2BA@mail.gmail.com> <E08E39A9-69E5-4E0C-85E1-0207A3E8AC7E@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Feb 12, 2013 at 7:59 PM, Warner Losh <imp@bsdimp.com> 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 <des@des.no> = wrote: > > > >> Mehmet Erol Sanliturk <m.e.sanliturk@gmail.com> 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 > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOgwaMuZ4smc3%2BDR64-b9-yXwODA-BoHTBtBOB0OvEaRUcTbqg>