| |||||||||||||
Who is the best inliner of all?Who is the best inliner of all?Posted Jan 15, 2009 9:47 UTC (Thu) by michaeljt (subscriber, #39183)Parent article: Who is the best inliner of all?
> We get oopses that have a nice symbolic back-trace, and it reports an error IN TOTALLY THE WRONG FUNCTION, because gcc "helpfully" inlined things to the point that only an expert can realize "oh, the bug was actually five hundred lines up, in that other function that was just called once, so gcc inlined it even though it is huge".
Smarter debug symbols/information might also help.
(Log in to post comments)
Who is the best inliner of all? Posted Jan 19, 2009 1:00 UTC (Mon) by i3839 (guest, #31386) [Link]
No, that won't help. Because all the information already exists in the debugging info, but loading all that debugging info (like line numbers) in a running kernel would waste way too much memory. Much more than is saved by aggressive inlining.
In this particular case it was about static functions with one caller, which in general makes perfect sense to inline, but not for the kernel, because when making a backtrace the kernel only has access to the information loaded in memory at that time.
Who is the best inliner of all? Posted Jan 19, 2009 8:40 UTC (Mon) by michaeljt (subscriber, #39183) [Link]
Why does the debug information have to be in memory at all when the kernel is running? The symbol resolution in the stack trace is not needed until the report is sent off, so it can be delayed until then.
Who is the best inliner of all? Posted Jan 19, 2009 9:12 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
for the symbol resolution to be done later, someone will have to manually transcribe the oops message (most of the time), when the kernel knows that it's in bad shape you really don't want to have it writing to a disk (it may end up writing over your data)
Linus' statement about digital cameras being are more useful than crash dumps for kernel debugging is becouse it's easy to take a picture of an oops and send it out, it's much more work (and therefor fewer people bother) to gather the oops in other ways.
Who is the best inliner of all? Posted Jan 23, 2009 22:41 UTC (Fri) by oak (subscriber, #2786) [Link]
> for the symbol resolution to be done later, someone will have to
> manually transcribe the oops message (most of the time), when > the kernel knows that it's in bad shape you really don't want > to have it writing to a disk (it may end up writing over your data)
Maybe on production systems, but on test systems you really do want those
If disk is too risky for Oops information, send them to serial or over
Who is the best inliner of all? Posted Jan 20, 2009 1:31 UTC (Tue) by i3839 (guest, #31386) [Link]
Besides the reasons given by dlang, another one is that doing that is only possible if you have the debugging info of the running kernel, which might not always be the case (either for the user or the person receiving a raw oops).
And finally, it may not be strictly necessary and you could ask people to decipher cryptic messages one way or the other, but debugging the kernel should be as easy as possible. If you want to move the symbol resolution to user space to save kernel memory, you better also move all printk strings to user space as well, as that saves a lot of memory as well.
|
|||||||||||||