|
From: Paul M. <le...@li...> - 2003-07-13 19:56:31
|
On Mon, Jul 07, 2003 at 03:59:35PM +0100, Richard Curnow wrote: > what. So unless the app and all relevant libraries are compiled with > -g, the backtracing doesn't proceed very far (actually, back as far as > the first frame with no -g information.) >=20 Well, based off of this, the kernel backtrace should still be accurate for backtracing through the first stack frame, just not further. This is still useful for tracking an implicit crash location with the type of crash already determined ahead of time. In my initial tests of this, I've been unwinding the stack early on, and I hadn't noticed any oddities in the backtrace at that point -- though it wasn't tracing very far back either. Anyways, from the sounds of it, we'll need to have the symbol table availab= le in the kernel to actually make much additional use out of it (and trace back much further -- due to unlinked strack frames). I'm not sure how feasible this will be under 2.4, as it doesn't support a facility for this. Under 2.5 however, turning on CONFIG_KALLSYMS builds all of that in at link time, so we should be able to do something there (other architectures use this for things like print_symbol(), so that the symbol name can be decoded directly on the initial backtrace without relying on ksymoops traces). For 2.4, we're probably better off just not worrying about it, or simply adding a comment into the existing backtrace code outlining its limited usefulness. At this point, 2.6 isn't far off, so I'd much rather focus on getting this sort of stuff functional in 2.5 instead of spending more time on 2.4 (which at this point should mostly be limited to stability fixes, in my opinion). |