On Fri, 2009-01-09 at 12:29 -0800, Linus Torvalds wrote: > > On Fri, 9 Jan 2009, Nicholas Miell wrote: > > > > Maybe the kernel's backtrace code should be fixed instead of blaming > > gcc. > > And maybe people who don't know what they are talking about shouldn't > speak? I may not know what I'm talking about, but you don't have to be rude about it, at least not until I've made a nuisance of myself, and a single mail surely isn't yet a nuisance. > You just loaded the whole f*cking debug info just to do that exact > analysis. Guess how big it is for the kernel? It's huge, I know. My understanding is that the DWARF size could be reduced rather dramatically if redundant DIEs were coalesced into a single entry. Even then it would still be too large to load into the kernel for runtime stack trace generation, but that's what the offline analysis of crash dumps is for. > Did you even read this discussion? No, I didn't read most of the discussion, I only started skimming it after I saw the gcc people talking negatively about the latest brouhaha. (And this thread being an offshoot of a large thread that is itself an offshoot of another large thread certainly didn't help me find the relevant parts of the discussion, either). So I'm sorry that I missed whatever comments you made on the subject (As an aside, I'm amazed that anything works at all when the kernel, compiler and runtime library people all seem to mutually loathe each other to the point of generally refusing to communicate at all.) > Did you see my comments about why > kernel backtrace debugging is different from regular user mode debugging? I think I found the mail in question[1], and after reading it, I found that it touches on one of the things I was thinking about while looking through the thread. The majority of code built by gcc was, is and always will be userspace code. The kernel was, is and always will be of minor importance to gcc. gcc will never be perfect for kernel use. So take your complaint about gcc's decision to inline functions called once. Ignore for the moment the separate issue of stack growth and let's talk about what it does to debugging, which was the bulk of your complaint that I originally responded to. In the general case is it does nothing at all to debugging (beyond the usual weird control flow you get from any optimized code) -- the compiler generates line number information for the inlined functions, the debugger interprets that information, and your backtrace is accurate. It is only in the specific case of the kernel's broken backtrace code that this becomes an issue. It's failure to function correctly is the direct result of a failure to keep up with modern compiler changes that everybody else in the toolchain has dealt with. So putting "helpfully" in sarcastic quotes or calling what gcc does a gcc problem is outright wrong. For most things, gcc's behavior does actually help, and it is a kernel's problem (by virtue of the kernel being different and strange), not gcc's. The question then becomes, how does the kernel deal with the fact that it is of minor importance to gcc and significantly different from the bulk of gcc's consumers to the point where those differences become serious problems? I think that the answer to that is that the kernel should do its best to be as much like userspace apps as it can, because insisting on special treatment doesn't seem to be working. In this specific case, that would mean make kernel debugging as much like userspace debugging as you can -- stop pretending that stack traces generated by the kernel at runtime are adequate, get kernel crash dumps enabled and working 100% of the time, and then use a debugger to examine the kernel's core dump and find your stack trace. As an added bonus, real crash dumps aren't limited just to backtraces, so you'd have even more information to work with to find the root cause of the failure. [1] Message ID: alpine.LFD.2.00.0901090947080.6528@xxxxxxxxxxxxxxxxxxxxx -- Nicholas Miell <nmiell@xxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
