Re: Kernel Panic, Backtrace, GDB, and Optimizations
Re: Kernel Panic, Backtrace, GDB, and Optimizations
- Subject: Re: Kernel Panic, Backtrace, GDB, and Optimizations
- From: Terry Lambert <email@hidden>
- Date: Wed, 21 Sep 2005 21:17:56 -0700
For kernel debugging, it's actually impossible to compile a working
xnu kernel without some optimizations, due to the layout of the
kernel virtual address space.
In general, the main places you will see the stack look strange are:
1) If you run into a tail-call optimization; a tail call will make
it look like the function that is being called from the function that
is optimized as if it is being called directory. This is because
there is no stack frame since it's handled by a jump instruction, so
the tail call optimization will make things look like they are being
called from places they are not. You can specifically ask the
compiler not to do tail-call optimization at even high optimization
levels by specifying:
-fno-optimize-sibling-calls
2) If your code honestly goes off in the weeds, either through
stack smashing or through an uninitialized function pointer/bad
function pointer, then the stack will look screwy. You're kind of on
your own there.
3) If your code uses a function pointer, it can look fairly
screwy, unless you know this is happening. For IP filters, this is
almost always the case, since the IP Filter code is built on callback
lists of function pointers, so it can look like your code is being
called from anywhere, because, well, it might be. You are best off
to reference the Darwin sources when you see something strange in
this area.
4) Another thing that can somewhat mess you up, particularly when
dealing with breakpoints is speculative execution; occasionally, I've
had code where it was (effectively) impossible to breakpoint entry
into a function, unless you disassembled the function in the debugger
and set the breakpoint on an assembly language instruction instead of
a C symbol or line. This would qualify as a gcc/gdb bug (in my
book), since you'd think it would communicate the information about
code reordering/etc. via corrected stabs.
Other than that, I debug optimized kernels on a daily basis, and even
though it's the recognized folklore that you can't really trust the
source code matches the object code, I really don't see a lot of
problems; I think people are mostly referring to older tool-chains
when they speak about this being an issue.
-- Terry
On Sep 21, 2005, at 1:58 PM, Brian Bergstrand wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Debugging any compiled object (app, kernel extension, lib) is
generally useless with compiler opts turned on (as you have seen).
If you are doing active debugging, turn them off, that's why XCode
has Debug and Release Configurations -- so you can have both non-
optimized and optimzed builds.
On Sep 21, 2005, at 3:08 PM, Frank Thomas wrote:
I have been doing some debug work on an occasional kernel panic we
have been having with our kernel extension installed (IP Filter).
Some of the back traces we have gotten have made perfect sense.
You can see the backtrace running back through the code in the
proper execution order. A few have had backtraces that just can't
happen in the code. For instance a function that would never be
called from another function. The ones I have had the best luck
backtracing with GDB are when the kernel extension has been
compiled with compiler optimizations for "Fastest Smallest".
When compiled with "Faster" optimization the backtrace didn't at
all make sense. Maybe something with debug symbols and opts are
getting screwed up and pointing me at the wrong point of code?
I'm always generating a symbol file from my kext with the base
address reported for the kext in the kernel panic and loading it
before I do the backtrace. So I am pretty sure it isn't a case of
looking at a bad symbol file.
I say all that to ask this. What has expereince been with kernel
panics and compiler optimizations? Would it better for me to run
no opts during a process like this? Are thier optimizations that
should just be totally avoided when doing a kernel extension? I
appreciate any feedback you may have.
Sincerely
Brian Bergstrand
<http://www.bergstrand.org/brian/> PGP Key ID: 0xB6C7B6A2
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden