Date: Fri, 19 Oct 2001 20:19:19 +0800 From: Trent Nelson <nelsont@switch.aust.com> To: freebsd-arch@FreeBSD.org Subject: Proposal: kernel/module debugging support improvements. Message-ID: <20011019201919.L23852@freebsd06.udt>
next in thread | raw e-mail | index | archive | help
There's currently a deficiency in our build process that prevents you from *preventing* the installation of stripped kernel modules when DEBUG has been defined. In sys/conf/kmod.mk: .if !defined(DEBUG) FULLPROG= ${PROG} .else FULLPROG= ${PROG}.debug ${PROG}: ${FULLPROG} ${OBJCOPY} --strip-debug ${FULLPROG} ${PROG} .endif I'd like to have the capability of stipulating that I specifically *DON'T* want to strip debugging symbols from my kernel modules before they're installed. One of the main reasons I'd want to do something like this is to easily facilitate debugging of kernel modules through say, remote gdb, when access to the modules with debugging symbols may not be readily available. It's obvious that there's going to be people on the other side of the fence who want to have kernel modules with debugging information available if need be -- but want the stripped objects in /boot/kernel. So, a solution needs to cater for both parties. There's a few options of achieving this functionality, so I'd like to hear peoples' comments. 1. Introducing an ``install.debug'' target to sys/conf/kmod.mk. Advantages of this is it is consistent with the ``install.debug'' target already present in the kernel Makefile. If this approach is to be used -- it's worthwhile to have these present in /usr/src/Makefile.inc1 also. 2. Introducing ``KERNEL_STRIP'' & ``MODULE_STRIP'' variables. This would be consistent with the ``STRIP'' variable used in the userland build process. Doing it this way has the disadvantage of introducing two variables whose semantics derive implicitly upon whether or not DEBUG is set. Comments? Regards, Trent. -- Trent Nelson - Software Engineer - nelsont@switch.aust.com "A man with unlimited enthusiasm can achieve almost anything." --unknown To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011019201919.L23852>