Date: Fri, 7 Dec 2012 11:35:30 +0530 From: Shrikanth Kamath <shrikanth07@gmail.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: ELF symtab and ddbsymtab difference Message-ID: <CAEOAkMUJLv%2BKNvP0k6rXbPeBpaqiLzf-r5Hdp0h-rhToW4UKKg@mail.gmail.com> In-Reply-To: <20121206231122.GE3013@kib.kiev.ua> References: <CAEOAkMU0osWoUensNaqBH%2BPWP9bcTLZffwLVh3WeppzqKMmT0g@mail.gmail.com> <20121206231122.GE3013@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks Konstantin, yeah I think there were two levels of strip
happening, one removing the debug sections and another
was removing the .strtab and .symtab. I have EXPORT_SYMS = YES in my
Makefile but that was not helping as the
variables in context are declared static (they are going into the
.bss). Making it un-static helps or avoiding the second
level strip helps too..
--
Shrikanth R K
On Fri, Dec 7, 2012 at 4:41 AM, Konstantin Belousov <kostikbel@gmail.com> wrote:
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAEOAkMUJLv%2BKNvP0k6rXbPeBpaqiLzf-r5Hdp0h-rhToW4UKKg>