[Bug 293536] kgdb: source code location lookup works for kernel but not for module

From: <bugzilla-noreply_at_freebsd.org>
Date: Mon, 02 Mar 2026 00:40:06 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293536

            Bug ID: 293536
           Summary: kgdb: source code location lookup works for kernel but
                    not for module
           Product: Base System
           Version: 16.0-CURRENT
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: cracauer@cons.org

tl;dr:

I have a bhyve kgdb situation, debugging a module. The source code is synced
between guest and host, both located at /usr/src-debug. However, the debugger
insists on using /usr/src for the module, although the correct /usr/src-debug
is used for the kernel. Consider this backtrace:

#0  panic (fmt=0xffffffff83012022 "No cnp")
    at /usr/src-debug/sys/kern/kern_shutdown.c:886
#1  0xffffffff830116a0 in sysctl_rule (oidp=<optimized out>,
    arg1=0x0 <ugidfw_check>, arg2=-2097078112, req=0xffffffff830120a0)
    at /xcarb3/usr/src/sys/security/mac_bsdextended/mac_bsdextended.c:145
#2  0xffffffff83011714 in sysctl_rule (oidp=<optimized out>,
    arg1=<optimized out>, arg2=<optimized out>, req=0x40 <ugidfw_check+64>)
    at /xcarb3/usr/src/sys/security/mac_bsdextended/mac_bsdextended.c:154
#3  0xffffffff80f3c56b in mac_vnode_check_lookup_impl (
    cred=cred@entry=0xfffff8037415ed80, dvp=dvp@entry=0xfffff80001b0a1b8,
    cnp=0xfffffe00d5fa68f8, cnp@entry=0xfffffe00d5fa6d18)
    at /usr/src-debug/sys/security/mac/mac_vfs.c:576
#4  0xffffffff80cc5a7d in mac_vnode_check_lookup (cred=0xfffff8037415ed80,
    dvp=0xfffff80001b0a1b8, cnp=0xfffffe00d5fa6d18)
    at /usr/src-debug/sys/security/mac/mac_framework.h:565
#5  vfs_lookup (ndp=ndp@entry=0xfffffe00d5fa6c98)
    at /usr/src-debug/sys/kern/vfs_lookup.c:1311
#6  0xffffffff80cc472d in namei (ndp=ndp@entry=0xfffffe00d5fa6c98)
    at /usr/src-debug/sys/kern/vfs_lookup.c:738
#7  0xffffffff80cefd52 in vn_open_cred (ndp=ndp@entry=0xfffffe00d5fa6c98,
    flagp=flagp@entry=0xfffffe00d5fa6db4, cmode=cmode@entry=420,
--Type <RET> for more, q to quit, c to continue without paging--
    vn_open_flags=vn_open_flags@entry=16, cred=0xfffff8037415ed80,
fp=0xfffff8000583a050) at /usr/src-debug/sys/kern/vfs_vnops.c:369
#8  0xffffffff80ce5747 in openatfp (td=0xfffff8000584b000,
dirfd=dirfd@entry=-100, path=0x824cba112 "/var/run/utx.active",
pathseg=pathseg@entry=UIO_USERSPACE, flags=1048577,
    mode=<optimized out>, fpp=0x0 <ugidfw_check>) at
/usr/src-debug/sys/kern/vfs_syscalls.c:1263
#9  0xffffffff80ce5408 in kern_openat (td=0xffffffff83012022, dirfd=-100,
path=0xffffffff830120a0 "FOO3: '%s'\n", pathseg=UIO_USERSPACE, flags=92581888,
mode=-2111371672)
    at /usr/src-debug/sys/kern/vfs_syscalls.c:1351


As you can see /xcarb3/usr/src is used for the module (which is the unedited
host source code). The correct /usr/src-debug is used for the kernel.

Inside, kernel.debug and mac_bsdextended.ko.debug both clearly reference
/usr/src-debug if you inspect the files in a hexdump.

Longer story:
-------------

I am bringing things into play like this:
- source code is in /usr/src-debug on both guest and host
- guest compiles, installs and runs the modified kernel and module
- kernel.debug and mac_bsdextended.ko.debug are copied to /var/tmp on the host
- invocation:
kgdb /var/tmp/kernel.debug
add-symbol-file /var/tmp/mac_bsdextended.ko.debug
target remote localhost:1234
b panic

When starting kgdb says
Reading symbols from /var/tmp/kernel.debug...                                   
add symbol table from file "/var/tmp/mac_bsdextended.ko.debug"                  
warning: remote target does not support file transfer, attempting to access
file
s from local filesystem.                                                        


Obviously that "from local filesystem" could screw me up, but it doesn't say
that it actually loads something.

-- 
You are receiving this mail because:
You are the assignee for the bug.