On Wed, Dec 05, 2012 at 12:13:24PM +0530, Shrikanth Kamath wrote: > This is regarding the fields in the structure "elf_file_t" in link_elf.c. > For some kernel modules the symtab field is different from the ddbsymtab > field for some it is the same, would like to know what is the difference > between the two and how to enable ddbsymtab? Assuming we are talking about the link_elf.c and not about link_elf_obj.c. The symtab and ddbsymtab are first initialized from the dynamic symbol table in the module, and later, in the process of loading the module, if the non-dynamic symbol table is present, ddbsymtab is rewritten to point to the table.
>
> Does enabling "-g" in CFLAGS make the binary build the ddbsymtab different
> from symtab?
No. It is strip done on the module which could result in the removal of the
non-dynamic symtab.
>
> The problem is lookup for some symbols in the kernel module that I built
> returns with undefined, on inspecting it was getting a ENOENT from the
> function
> link_elf_lookup_symbol()
> {
> ...
> /* If we have not found it, look at the full table (if loaded) */
> if (ef->symtab == ef->ddbsymtab)
> return (ENOENT);
> ...
> }
It is not the problem. It just means that you dynamic symbol table does
not contain the needed symbol, which is the problem. As a coincident,
you also stripped your module, making the problem to be exposed.
I guess that you should look at the EXPORT_SYMS feature of the module
Makefiles. But I also remember there were some bugs.
pgpYNFsprvOlA.pgp
Description: PGP signature
