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
signature.asc
Description: This is a digitally signed message part.