Skip site navigation (1)Skip section navigation (2)
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>