Bug 232829

Summary: Kernel debugger only reads .dynsym even if .symtab exists
Product: Base System Reporter: Alex Richardson <arichardson>
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: New ---    
Severity: Affects Some People CC: cem
Priority: ---    
Version: CURRENT   
Hardware: Any   
OS: Any   

Description Alex Richardson freebsd_committer 2018-10-30 21:32:43 UTC
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.
Comment 1 Conrad Meyer freebsd_committer 2018-10-30 23:09:45 UTC
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:

297         ${OBJCOPY} --strip-debug --add-gnu-debuglink=${SHLIB_NAME}.debug \
298             ${SHLIB_NAME_FULL} ${.TARGET}
304         ${OBJCOPY} --only-keep-debug ${SHLIB_NAME_FULL} ${.TARGET}

Apparently --strip-debug leaves SYMTAB if one was present.)
Comment 2 Conrad Meyer freebsd_committer 2018-10-30 23:14:36 UTC
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.