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

[Mehmet Erol Sanliturk]

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 :

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 .

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 .


Thank you very much .

Mehmet Erol Sanliturk