From owner-freebsd-amd64@FreeBSD.ORG Thu Oct 27 15:32:30 2005 Return-Path: X-Original-To: amd64@FreeBSD.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1FA3C16A41F; Thu, 27 Oct 2005 15:32:30 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74E0143D45; Thu, 27 Oct 2005 15:32:29 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j9RFWR2q023715; Thu, 27 Oct 2005 18:32:27 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 82407-04-2; Thu, 27 Oct 2005 18:32:24 +0300 (EEST) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j9RFTFSE023609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Oct 2005 18:29:15 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.4/8.13.4) id j9RFTHod063640; Thu, 27 Oct 2005 18:29:17 +0300 (EEST) (envelope-from ru) Date: Thu, 27 Oct 2005 18:29:17 +0300 From: Ruslan Ermilov To: Jung-uk Kim , Peter Wemm , Ian Dowse Message-ID: <20051027152917.GE68470@ip.net.ua> References: <200510250905.j9P9575Z002500@repoman.freebsd.org> <200510261706.50768.jkim@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="a2FkP9tdjPU2nyhF" Content-Disposition: inline In-Reply-To: <200510261706.50768.jkim@FreeBSD.org> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua Cc: amd64@FreeBSD.org Subject: kldloading foo.ko.debug on amd64 (was: Re: cvs commit: src/release Makefile src/sys/conf kern.post.mk kmod.mk) X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2005 15:32:30 -0000 --a2FkP9tdjPU2nyhF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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=3D-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 >=20 > It's broken amd64. I had DEBUG=3D-g in the configuration and it's=20 > spewing a lot of 'kldload: unexpected relocation type 10' while=20 > preloading modules. :-( >=20 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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 =20 for (i =3D 0; i < ef->nprogtab; i++) { if ((strncmp(ef->progtab[i].name, "set_", 4) =3D=3D 0) && - strcmp(ef->progtab[i].name + 4, name) =3D=3D 0) { + (strcmp(ef->progtab[i].name + 4, name) =3D=3D 0) && + ef->e_shdr[ef->progtab[i].sec].sh_type =3D=3D SHT_PROG= BITS) { *startp =3D (char *)ef->progtab[i].addr - ef->address; *stopp =3D (char *)ef->progtab[i].addr + ef->progtab[i].size - ef->address; %%% Anyway, I'd appreciate some enlightment and help. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --a2FkP9tdjPU2nyhF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDYPJNqRfpzJluFF4RAjUtAJ9JH0+FWA2ued4f4iuIayMaJRJ76wCgnvoR 0Pddc2tKZF7E7zJAZWoEo/0= =E9bT -----END PGP SIGNATURE----- --a2FkP9tdjPU2nyhF--