Date: Sun, 16 Nov 2003 23:14:23 -0500 From: Michael Edenfield <kutulu@kutulu.org> To: Harald Schmalzbauer <h@schmalzbauer.de> Cc: current@freebsd.org Subject: Re: General debug/kernel question Message-ID: <20031117041423.GA15294@wombat.localnet> In-Reply-To: <200311170243.18436@harrymail> References: <200311170243.18436@harrymail>
next in thread | previous in thread | raw e-mail | index | archive | help
--Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Harald Schmalzbauer <h@schmalzbauer.de> [031116 20:43]: Content-Description: signed data > Salve, >=20 > I always thought that building a kernel with debug symbols would increase= the=20 > kernel size dramatically. But if I understand things right the additioal= =20 > "symbols" (code snippets?) are not in the kernel but in a different file= =20 > which makes the kernel the same size like without debug=3D-g. Is there an= y=20 > reason to not build it with debug=3D-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=20 > in my kernel and don't _feel_ any difference. So again, is there any reas= on=20 > 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 --Kj7319i9nmIyA2yE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD4DBQE/uEsfCczNhKRsh48RAms7AJdFhlCGlpwUlt27amSwTf1iTqrWAJ4wj1Rc CZ41Wv9qNqSauvU/pDPqHA== =RZmv -----END PGP SIGNATURE----- --Kj7319i9nmIyA2yE--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031117041423.GA15294>