system.map in linux

In Linux, the System.map file is a symbol table used by the kernel.
A symbol table is a look-up between symbol names and their addresses in memory. A symbol name may be the name of a variable or the name of a function. The System.map is required when the address of a symbol name, or the symbol name of an address, is needed. It is especially useful for debugging kernel panics and kernel oopses. The kernel does the address-to-name translation itself when CONFIG_KALLSYMS is enabled so that tools like ksymoops are not required

Internals

The following is part of a System.map file:

c041bc90 b packet_sklist
c041bc94 b packet_sklist_lock
c041bc94 b packet_socks_nr
c041bc98 A __bss_stop
c041bc98 A _end
c041c000 A pg0
ffffe400 A __kernel_vsyscall
ffffe410 A SYSENTER_RETURN
ffffe420 A __kernel_sigreturn
ffffe440 A __kernel_rt_sigreturn

Because addresses may change from one build to the next, a new System.map is generated for each build of the kernel.

Symbol types

The character between the address and the symbol (separated by spaces) is the type of a symbol. The nm utility program on Unix systems list the symbols from object files. The System.map is directly related to it, in that this file is produced by nm on the whole kernel program – just like nm lists the symbols and their types for any small object programs^.
Some of these types are:

• A for absolute
• B or b for uninitialized data section (called BSS)
• D or d for initialized data section
• G or g for initialized data section for small objects (global)
• i for sections specific to DLLs
• N for debugging symbol
• p for stack unwind section
• R or r for read only data section
• S or s for uninitialzed data section for small objects
• T or t for text (code) section
• U for undefined
• V or v for weak object

Filesystem location

After building the Linux kernel, System.map is located in the root of the source directory. However, some further software installation steps expect to locate the file elsewhere:

• as /boot/System.map-$(uname -r)
• building SVGALib expects to find /lib/modules/$(uname -r)/build/System.map
•  
• 1. The format is similar to that of the output of nm utility, see also this page.
     To put it simple, 'T' usually denotes a global (non-static but not necessarily exported) function, 't' - a function local to the compilation unit (i.e. static), 'D' - global data, 'd' - data local to the compilation unit. 'R' and 'r' - same as 'D'/'d' but for read-only data.
  2. These are the items from the special sections needed to export symbols so that the symbols could be used by kernel modules.
     For each exported symbol, al least the following is defined by EXPORT_SYMBOL():
     
     • __kstrtab_<symbol_name> - name of the symbol as a string
     • __ksymtab_<symbol_name> - a structure with the information about the symbol: its address, address of __kstrtab_<symbol_name>, etc.
     • __kcrctab_<symbol_name> - address of the control sum (CRC) of the symbol - it is used, for example, to check if the kernel or a module provides an exactly the same symbol as needed by a given kernel module. If a module requires a symbol with a given name and CRC and the kernel provides a symbol with that name but a different CRC (e.g. if the module was compiled for a different kernel version), the module loader will refuse to load that kernel module (unless this check is disabled).
     Take a look at the implementation of EXPORT_SYMBOL() macro in linux/export.h for details.
  3. Not sure but I have not encountered a situation so far when a function ("text symbol") or a variable ("data symbol") was present in System.map but not shown in /proc/kallsyms if the kernel is compiled properly and with kallsyms fully enabled (CONFIG_KALLSYMS=y, CONFIG_KALLSYMS_ALL=y). If CONFIG_KALLSYMS_ALL=n, only the functions (to be exact, symbols from *.text sections) will be shown in /proc/kallsyms.
  4. Depends on your kernel version. You can take a look at the definition of EXPORT_SYMBOL() for your kernel and find which type __ksymtab_<symbol_name> variables are. In the kernel 3.11, it is struct kernel_symbol defined in linux/export.h. Having the definition of that struct and its address, I suppose, you can get the address of the symbol: struct kernel_symbol::value. Haven't tried this myself though.
     Note, however, that __ksymtab_nf_hook is for nf_hook but not for nf_hooks. The name must match. nf_hooks and nf_hook are different entities.
  5. Hard to tell without seeing the code and the relevant part of /proc/kallsyms. Maybe it is #ifdef'ed out and not compiled at all, may be there is something else.
     Besides, nf_hooks is a data item so it might not show up in /proc/kallsyms if CONFIG_KALLSYMS_ALL is 'n'.