kldloading foo.ko.debug on amd64 (was: Re: cvs commit: src/release Makefile src/sys/conf kern.post.mk kmod.mk)

[Ruslan Ermilov]

On Wed, Oct 26, 2005 at 05:06:49PM -0400, Jung-uk Kim wrote:
> On Tuesday 25 October 2005 05:05 am, Ruslan Ermilov wrote:
[...]
> >   Now, if kernel was configured for debugging (through DEBUG=-g in
> >   the kernel config file or "config -g"), doing "make install" will
> >   install debug versions of kernel and module objects with their
> >   canonical names,
> >
> >           kernel.debug -> /boot/kernel/kernel
> >           if_fxp.ko.debug -> /boot/kernel/if_fxp.ko
> >
> >   Installing a kernel not configured for debugging, or debug kernel
> >   with INSTALL_NODEBUG variable defined, will install non-debug
> >   kernel and module objects.
> >
> >   Also, restore the install.debug and reinstall.debug targets that
> >   are part of the existing API (they cause some additional gdb(1)
> >   scripts to be installed).
> >
> >   Revision  Changes    Path
> >   1.891     +0 -4      src/release/Makefile
> >   1.86      +4 -2      src/sys/conf/kern.post.mk
> >   1.197     +3 -8      src/sys/conf/kmod.mk
> 
> It's broken amd64.  I had DEBUG=-g in the configuration and it's 
> spewing a lot of 'kldload: unexpected relocation type 10' while 
> preloading modules. :-(
> 
Fixing the above warning would be easy, but the problem was worse:
kldloading a module object with debugging infomation would consume
a lot more memory, on amd64.  This has something to do with a
different format of kernel object flies, because on i386 loading
either module consumes the same amount of memory (as reported by
kldstat(8)).

Peter, Ian, can you please explain what's different here?
I.e., why loading a foo.ko.debug on amd64 consumes more space
than loading a foo.ko, contrary to say i386?

After figuring this out, I adopted the code proposed by obrien.
Now we build a "two part executable", foo.ko and accompanying
foo.ko.dbg that the gdb(1) knows how to pick up.  This upsets
kldxref(8), because they have the module metadata section to be
of type SHT_NOBITS instead of SHT_PROGBITS, so reading from this
section essentially returns zeroes:

kldxref: unknown metdata record 0 in file if_xl.ko.dbg
kldxref: unknown metdata record 0 in file if_xl.ko.dbg
kldxref: unknown metdata record 0 in file if_xl.ko.dbg
kldxref: unknown metdata record 0 in file if_xl.ko.dbg
kldxref: unknown metdata record 0 in file if_xl.ko.dbg
kldxref: unknown metdata record 0 in file if_xl.ko.dbg

I have a fix for this, but I'm not sure if it's right:

%%%
Index: ef_obj.c
===================================================================
RCS file: /home/ncvs/src/usr.sbin/kldxref/ef_obj.c,v
retrieving revision 1.3
diff -u -p -r1.3 ef_obj.c
--- ef_obj.c	28 Aug 2004 19:31:10 -0000	1.3
+++ ef_obj.c	27 Oct 2005 13:50:52 -0000
@@ -164,7 +164,8 @@ ef_obj_lookup_set(elf_file_t ef, const c
 
 	for (i = 0; i < ef->nprogtab; i++) {
 		if ((strncmp(ef->progtab[i].name, "set_", 4) == 0) &&
-		    strcmp(ef->progtab[i].name + 4, name) == 0) {
+		    (strcmp(ef->progtab[i].name + 4, name) == 0) &&
+                    ef->e_shdr[ef->progtab[i].sec].sh_type == SHT_PROGBITS) {
 			*startp = (char *)ef->progtab[i].addr - ef->address;
 			*stopp = (char *)ef->progtab[i].addr +
 			    ef->progtab[i].size - ef->address;
%%%

Anyway, I'd appreciate some enlightment and help.


Cheers,
-- 
Ruslan Ermilov
ru at FreeBSD.org
FreeBSD committer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-amd64/attachments/20051027/5451243c/attachment.bin