Re: Kernel Panic, Backtrace, GDB, and Optimizations
Re: Kernel Panic, Backtrace, GDB, and Optimizations
- Subject: Re: Kernel Panic, Backtrace, GDB, and Optimizations
- From: Brian Bergstrand <email@hidden>
- Date: Wed, 21 Sep 2005 23:23:14 -0500
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sep 21, 2005, at 11:17 PM, Terry Lambert wrote:
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.
Ah, good to know.
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.
That has not been my experience with applications, libs and kext's.
Debugging any of those with the latest tool chain (gcc 4, etc) with
optimizations turned on usually causes some kind of confusion when
doing source debugging.
-- 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFDMjG3edHYW7bHtqIRAhaeAJ9ci0mHbcL+5d/3kfrlDFbDMRvmDQCbB7oM
DwCUiAffORe6qU6zx2dbZNk=
=K0K3
-----END PGP SIGNATURE-----
_______________________________________________
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
- Prev by Date:
Re: Kernel Panic, Backtrace, GDB, and Optimizations
- Next by Date:
Re: Kernel Panic, Backtrace, GDB, and Optimizations
- Previous by thread:
Re: Kernel Panic, Backtrace, GDB, and Optimizations
- Next by thread:
Re: Kernel Panic, Backtrace, GDB, and Optimizations
- Index(es):