freebsd stable - Jan 2008 - kldstat causes kernel to print odd message

Hi,
I have built my own release of 6.3 (slightly older than 6.3 as tagged) 
and I am seeing an odd cosmetic problem. Whenever I kldload a module 
(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 
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* 
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 
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 
not sure why they both exist though.

The one in link_elf.c fails at..
    if (hdr->e_type != ET_EXEC && hdr->e_type != ET_DYN) {
        link_elf_error("Unsupported file type");
        error = 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 
ordering issue where normally elf64_obj is called first so the other is 
normally never called..)

Thanks.

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part.
Url :
http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080117/ed09b5b3/attachment.pgp

On Wednesday 16 January 2008 10:40:25 pm Daniel O'Connor
wrote:
> Hi,
> I have built my own release of 6.3 (slightly older than 6.3 as tagged) 
> and I am seeing an odd cosmetic problem. Whenever I kldload a module 
> (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)
> Can anyone explain what the underlying problem is? (I am guessing some 
> ordering issue where normally elf64_obj is called first so the other is 
> normally never called..)
> 
> Thanks.
amd64 uses link_elf_obj.c, all the other archs use link_elf.c, hence the 
duplication.  link_elf.c is used to load kld's that are ELF shared objects 
(i.e. foo.so) where as link_elf_obj.c is used to load kld's that are ELF 
objects (i.e. foo.o).  I think you are going to get this everytime you do a 
kldload on amd64 because it will always try link_elf.c first due to compile 
order (MI files are ordered in the makefile before MD ones), emit the 
warning, and then try link_elf_obj.c.

-- 
John Baldwin