Bug 232829 - Kernel debugger only reads .dynsym even if .symtab exists
Summary: Kernel debugger only reads .dynsym even if .symtab exists
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-10-30 21:32 UTC by Alex Richardson
Modified: 2018-10-30 23:14 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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:

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.)
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.