Skip site navigation (1)Skip section navigation (2) 
Date:      Thu, 17 Jan 2008 14:10:25 +1030
From:      "Daniel O'Connor" <doconnor@gsoft.com.au>
To:        freebsd-stable@freebsd.org
Subject:   kldstat causes kernel to print odd message
Message-ID:  <200801171410.38488.doconnor@gsoft.com.au>
next in thread | raw e-mail | index | archive | help 
--nextPart1694949.LQK0J3eQ1o
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi,
I have built my own release of 6.3 (slightly older than 6.3 as tagged)=20
and I am seeing an odd cosmetic problem. Whenever I kldload a module=20
(stuff loaded by the loader doesn't do it) I get this in dmesg..
kldload: Unsupported file type

The actual module works fine though (shows up in kldstat etc)

I traced the call path kldstat -> linker_load_module -> linker_load_file
And it seems that the TAILQ_FOREACH() in linker_load_file is iterating=20
over 2 things - 'elf64' and 'elf64_obj'.

LINKER_LOAD_FILE is defined by linker_if.m/h and looks like..
static __inline int LINKER_LOAD_FILE(linker_class_t cls, const char*=20
filename,
                                     linker_file_t* result)
{
        kobjop_t _m;
        KOBJOPLOOKUP(cls->ops,linker_load_file);
        return ((linker_load_file_t *) _m)(cls, filename, result);
}

Now it seems that link_elf.c and link_elf_obj.c both define identical=20
methods & function names with very similar code.

The one in link_elf_obj.c works and the one in link_elf.c doesn't.. I am=20
not sure why they both exist though.

The one in link_elf.c fails at..
    if (hdr->e_type !=3D ET_EXEC && hdr->e_type !=3D ET_DYN) {
        link_elf_error("Unsupported file type");
        error =3D ENOEXEC;
        goto out;
    }

I note that the _obj version checks if e_type is ET_REL (and lo it is).

Can anyone explain what the underlying problem is? (I am guessing some=20
ordering issue where normally elf64_obj is called first so the other is=20
normally never called..)

Thanks.

=2D-=20
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

--nextPart1694949.LQK0J3eQ1o
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)

iD8DBQBHjs425ZPcIHs/zowRAuHtAJ9uObo8vgtn16iNpZ8pYk6ZOYRq9wCeMW3k
Oj0aYIMs+eUmde4wFjWL154=
=zLmf
-----END PGP SIGNATURE-----

--nextPart1694949.LQK0J3eQ1o--

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200801171410.38488.doconnor>