Kernel symbol table

Kernel symbol table

[Shrinand Javadekar]

Hi All,

I have gdb attached to a running kernel. Even if the kernel was not
built with symbols, there should be some symbols exported by the
kernel right? The ones exported by using EXPORT_SYMBOL; e.g. sys_open,
sys_close, etc.

I believe these symbols are kept in the kernel symbol table. The
question I have is, how do I access this symbol table?

Also, does the kernel do anything special about where to keep (at what
address) this symbol table?

Thanks in advance.
-Shri

Re: Kernel symbol table

[Michael Snyder]

Shrinand Javadekar wrote:
> Hi All,
> 
> I have gdb attached to a running kernel. Even if the kernel was not
> built with symbols, there should be some symbols exported by the
> kernel right? The ones exported by using EXPORT_SYMBOL; e.g. sys_open,
> sys_close, etc.
> 
> I believe these symbols are kept in the kernel symbol table. The
> question I have is, how do I access this symbol table?
> 
> Also, does the kernel do anything special about where to keep (at what
> address) this symbol table?
> 
> Thanks in advance.
> -Shri

Shri,

If you build the kernel, the symbol file will be called "vmlinux"
in the top level of your build tree.  This is an elf file that gdb
can read.

You do not want the compressed file called "vmlinuz" (note 'z').
That file is not elf.

Cheers,
Michael

Re: Kernel symbol table

[Shrinand Javadekar]

Hi Michael,

Thanks for the reply. However, there are a couple of problems with
looking at vmlinux.

1. When I haven't built the kernel myself, I don't have the vmlinux file.
2. When I am remotely connected to a machine, I don't really have the
vmlinux file with me.

Hence, rather that getting the info statically from file, it would be
great to read it directly from the memory of the target.

-Shri

On Thu, Apr 9, 2009 at 11:44 AM, Michael Snyder <msnyder@vmware.com> wrote:
> Shrinand Javadekar wrote:
>>
>> Hi All,
>>
>> I have gdb attached to a running kernel. Even if the kernel was not
>> built with symbols, there should be some symbols exported by the
>> kernel right? The ones exported by using EXPORT_SYMBOL; e.g. sys_open,
>> sys_close, etc.
>>
>> I believe these symbols are kept in the kernel symbol table. The
>> question I have is, how do I access this symbol table?
>>
>> Also, does the kernel do anything special about where to keep (at what
>> address) this symbol table?
>>
>> Thanks in advance.
>> -Shri
>
> Shri,
>
> If you build the kernel, the symbol file will be called "vmlinux"
> in the top level of your build tree.  This is an elf file that gdb
> can read.
>
> You do not want the compressed file called "vmlinuz" (note 'z').
> That file is not elf.
>
> Cheers,
> Michael
>
>



-- 
Discover the 'web' of videos
www.videonym.com

Re: Kernel symbol table

[Michael Snyder]

Shrinand Javadekar wrote:
> Hi Michael,
> 
> Thanks for the reply. However, there are a couple of problems with
> looking at vmlinux.
> 
> 1. When I haven't built the kernel myself, I don't have the vmlinux file.
> 2. When I am remotely connected to a machine, I don't really have the
> vmlinux file with me.
> 
> Hence, rather that getting the info statically from file, it would be
> great to read it directly from the memory of the target.

Not possible, afaik.  The symbol sections of the vmlinu[x|z] file
are explicitly NOT loaded into memory.

Or were you thinking about some sort of /proc-like mechanism?

Re: Kernel symbol table

[Shrinand Javadekar]

Hi Michael,

If these are not loaded how can other (maybe even user written)
modules link to them?

For. e.g. I could write a simple driver which calls sys_open to open a
file. When the module is built/loaded, how does the linker/loader know
the address of sys_open?

-Shri

On Thu, Apr 9, 2009 at 1:24 PM, Michael Snyder <msnyder@vmware.com> wrote:
> Shrinand Javadekar wrote:
>>
>> Hi Michael,
>>
>> Thanks for the reply. However, there are a couple of problems with
>> looking at vmlinux.
>>
>> 1. When I haven't built the kernel myself, I don't have the vmlinux file.
>> 2. When I am remotely connected to a machine, I don't really have the
>> vmlinux file with me.
>>
>> Hence, rather that getting the info statically from file, it would be
>> great to read it directly from the memory of the target.
>
> Not possible, afaik.  The symbol sections of the vmlinu[x|z] file
> are explicitly NOT loaded into memory.
>
> Or were you thinking about some sort of /proc-like mechanism?
>

Re: Kernel symbol table

[Michael Snyder]

Shrinand Javadekar wrote:
> Hi Michael,
> 
> If these are not loaded how can other (maybe even user written)
> modules link to them?
> 
> For. e.g. I could write a simple driver which calls sys_open to open a
> file. When the module is built/loaded, how does the linker/loader know
> the address of sys_open?


I have no idea.  Maybe I should step aside and see if someone
who knows more will jump in.   ;-)

Re: Kernel symbol table

[Baurzhan Ismagulov]

On Thu, Apr 09, 2009 at 01:36:40PM -0700, Shrinand Javadekar wrote:
> If these are not loaded how can other (maybe even user written)
> modules link to them?

I think they are loaded, but I suppose it's (cross-)gdb on the host that
resolves the addresses to names (please correct me if I'm wrong); even
if it doesn't, I don't think the stub in the kernel supports reading
them. If you want to have them for symbolic debugging, you really want
vmlinux for full functionality -- it's more than just function names.

With kind regards,
-- 
Baurzhan Ismagulov
http://www.kz-easy.com/

Re: Kernel symbol table

[Jan Kratochvil]

On Thu, 09 Apr 2009 22:36:40 +0200, Shrinand Javadekar wrote:
> If these are not loaded how can other (maybe even user written)
> modules link to them?

kernel uses /proc/kallsyms which are stored in ELF-incompatible kernel custom
format.  You can get stripped ELF vmlinux file from vmlinuz by:

perl -e 'undef $/;$_=<>;print /(\x1f\x8b\x08.*$)/s;' <vmlinuz | gzip -d >vmlinux.bin

And there you can see these symbols by:

$ readelf -Wa vmlinux.bin
Section Headers:
  [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
  [ 8] __ksymtab         PROGBITS        ffffffff81482660 682660 00bb10 00   A  0   0 16
  [ 9] __ksymtab_gpl     PROGBITS        ffffffff8148e170 68e170 005420 00   A  0   0 16
  [10] __ksymtab_unused  PROGBITS        ffffffff81493590 693590 000010 00   A  0   0 16
  [11] __ksymtab_strings PROGBITS        ffffffff814935a0 6935a0 01303a 00   A  0   0  1
$ objcopy -j __ksymtab         -O binary vmlinux.bin vmlinux.bin-__ksymtab
$ objcopy -j __ksymtab_strings -O binary vmlinux.bin vmlinux.bin-__ksymtab_strings

You could write some script to extract this symbol information out of the
custom kernel __ksymtab* format into some readable format.

The better way would be to change Linux kernel to store its symbol information
in ELF format (such as common `.symtab' sections).


On Thu, 09 Apr 2009 20:59:54 +0200, Shrinand Javadekar wrote:
> 1. When I haven't built the kernel myself, I don't have the vmlinux file.

You should have debuginfo package for such kernel:
$ rpm -qlv kernel-debuginfo-2.6.28-3.fc10.x86_64 | grep vmlinux
-rwxr-xr-x    1 root    root    86367610 Jan 13 17:07 /usr/lib/debug/lib/modules/2.6.28-3.fc10.x86_64/vmlinux


> 2. When I am remotely connected to a machine, I don't really have the
> vmlinux file with me.

You can reassemble the kernel symbol table from __ksymtab* as listed above by
some custom code.  Or you can use the symbol table provided by the target
kernel itself as /proc/kallsyms.  You can also use System.map file which is
usually more commonly available that the vmlinux file.  For the latter two
source files you can use:

b=ffffffff81000000;sort </proc/kallsyms|perl -e 'print ".text\n";while (<>){($b,$s)=/^([0-9a-f]+) . (\S+)\s*$/s or next;next if $s{$s}++;$b=eval("0x$b-0x'$b'");next if $b<0 || $b>0x1000000 || $b{$b}++;printf "\t.org\t0x%x\n$s:\n",$b;}'|as -o /tmp/ker.o -;objcopy --adjust-vma=0x$b /tmp/ker.o

$ gdb /tmp/ker.o /proc/kcore
(gdb) disass printk
Dump of assembler code for function printk:
0xffffffff8132df6f <printk+0>:	push   %rbp
[...]
0xffffffff8132dfaf <printk+64>:	nop    
End of assembler dump.
(gdb) 

Generating the symbol file /tmp/ker.o has some drawbacks:
* You cannot simply generate ABS symbols by `.equ' as GDB requires the symbol
  to be SEC_CODE, therefore .text section relative.
* If you would generate such symbols by straight `.org' then:
  * gas crashes on 64-bit overflow on the 0xffffffff... addresses.
  * gas generates too big real zeroed .text section for the ker.o file.
* There are both address and symbol duplicates one could resolve better.
* 0xffffffff81000000 and 0x1000000 are x86_64 specific constants.



Regards,
Jan