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>