Proposal: Unify printing the function name in panic messages()

[Mehmet Erol Sanliturk]

On Tue, Feb 12, 2013 at 7:59 PM, Warner Losh <imp at 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ørgrav <des at des.no> wrote:
> >
> >> Mehmet Erol Sanliturk <m.e.sanliturk at gmail.com> 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ørgrav - des at 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 and
> 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
> >
>