Date: Tue, 12 Feb 2013 20:59:39 -0700 From: Warner Losh <imp@bsdimp.com> To: Mehmet Erol Sanliturk <m.e.sanliturk@gmail.com> Cc: Kirk McKusick <mckusick@mckusick.com>, =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= <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: <E08E39A9-69E5-4E0C-85E1-0207A3E8AC7E@bsdimp.com> In-Reply-To: <CAOgwaMvF%2BJ-ZQ3Bg0ZLVLv-7st0U7T%2BS6Vpd_Eubj_v83D7r%2BA@mail.gmail.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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <des@des.no> = wrote: >=20 >> Mehmet Erol Sanliturk <m.e.sanliturk@gmail.com> 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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E08E39A9-69E5-4E0C-85E1-0207A3E8AC7E>