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

[Warner Losh]

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.

> 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 .
> 
> 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
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"