Date: Thu, 27 Oct 2005 18:29:17 +0300 From: Ruslan Ermilov <ru@FreeBSD.org> To: Jung-uk Kim <jkim@FreeBSD.org>, Peter Wemm <peter@FreeBSD.org>, Ian Dowse <iedowse@FreeBSD.org> 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) Message-ID: <20051027152917.GE68470@ip.net.ua> In-Reply-To: <200510261706.50768.jkim@FreeBSD.org> References: <200510250905.j9P9575Z002500@repoman.freebsd.org> <200510261706.50768.jkim@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051027152917.GE68470>