Re: General debug/kernel question

* Harald Schmalzbauer <h_at_schmalzbauer.de> [031116 20:43]:
Content-Description: signed data
> Salve,
> 
> I always thought that building a kernel with debug symbols would increase the 
> kernel size dramatically. But if I understand things right the additioal 
> "symbols" (code snippets?) are not in the kernel but in a different file 
> which makes the kernel the same size like without debug=-g. Is there any 
> reason to not build it with debug=-g?

The debugging information doesn't appear in the installed kernel
(/boot/kernel/kernel for example).  The build process makes a kernel,
with debug symbols, in /usr/obj/usr/src/sys/KERNCONF.  It strips the
debugging information out before installing the file, though, because
it's pretty big.  The downside to adding -g to the build is just that
you take up more space in /usr which you may never use.

> Also I thought debug kernels suffer from reduced performance. I also have DDB 
> in my kernel and don't _feel_ any difference. So again, is there any reason 
> not to put DDB into the kernel?

DDB itself probably will never affect your performance in a noticeable
way unless your system crashed.  The problem with DDB is that, if you're
not present at the console when you get a kernel panic, the system hangs
waiting for you.  You can get around this by adding DDB_UNATTENDED, but
IMO this is pretty much worthless for anyone who's not a kernel
developer: you don't get to see the DDB screen and write down the
backtrace, and you don't get a crash dump that you can extract with
savecore.  Unless you plan to actually do debugging live in your kernel
I'd leave DDB off and set up a dump device instead.   This lets you go
back after a crash and extract information, by way of your debug kernel,
at your leisure.

The kernel debugging options that really kill performance are WITNESS
and especially INVARIANTS.  They cause a lot more debugging code to be
compiled into the kernel that's normally cut out, and run lots of extra
checks on locking and types and such at run-time.  WITNESS also tends to
procude excessive messages for potentially harmless problems.

--Mike