Recall that_export_symbol calls the_crc_symbol macro internally, as discussed in Section 7.3.3. This is defined as follows when version control is enabled:
extern void *_crc_##sym _attribute_((weak)); \
static const unsigned long __kcrctab_##sym \
_attribute_((section("_kcrctab" sec), unused)) \
When EXPORT_SYMBOL(get_shorty) is called,_CRC_SYMBOL expands as follows:
extern void *__crc_get_richard __attribute__((weak)); static const unsigned long __kcrctab_get_shorty _attribute_used_
(unsigned long) &__crc_get_shorty;
25For simplicity's sake, the parameters for matching the include paths to the kernel sources are not shown; also, in a genuine module compilation, -DMODULE, for example, would also be specified. Refer to the output of make modules for details.
As a result, the kernel creates two objects in the binary file:
□ The undefined void pointer_crc_function is located in the normal symbol table of the module. 26
□ A pointer to the variable just defined is stored under krcrtab_ function in the_kcrctab section of the file.
When the module is linked (in the first phase of module compilation), the linker uses the .ver file generated by genksyms as a script. This supplies the_crc_function symbols with the values in the script.
The kernel reads them in later. If another module refers to one of these symbols, the kernel uses the information shown here to ensure that both refer to the same version.
Continue reading here: Unresolved References
Was this article helpful?