The .symtab section contains all symbols (but may be stripped so is not necessarily present) whereas .dynsym only contains the exported symbols (i.e. not static). This causes backtraces to report some_other_function+large_offset if the backtrace pc is inside static function. If .symtab is present, link_elf_search_symbol() should be checking .symtab instead of .dynsymtab. However, it seems like ef->ddbsymtab always points to .dynsym and since I am not familiar with that code I couldn't see an easy way of using .symtab instead if it is available.
Seems like a good idea to me. On my local amd64 kernels, I see SYMTAB in the stripped binary (objdump -x) and not in the corresponding .debug file in /usr/lib/debug. (Conditional on MK_DEBUG_FILES, bsd.lib.mk splits full objects, including kernels, into stripped and debuginfo with: 296 ${SHLIB_NAME}: ${SHLIB_NAME_FULL} ${SHLIB_NAME}.debug 297 ${OBJCOPY} --strip-debug --add-gnu-debuglink=${SHLIB_NAME}.debug \ 298 ${SHLIB_NAME_FULL} ${.TARGET} ... 303 ${SHLIB_NAME}.debug: ${SHLIB_NAME_FULL} 304 ${OBJCOPY} --only-keep-debug ${SHLIB_NAME_FULL} ${.TARGET} Apparently --strip-debug leaves SYMTAB if one was present.)
A related but tangential is GNU hash support for symbol lookup by name and/or linking. amd64 .ko's are weird and not "finished" objects, so binutils doesn't generate a ".gnu.hash" section for them, but there's no reason we couldn't do so in elftoolchain or some trivial build tool.