[Bug 293536] kgdb: source code location lookup works for kernel but not for module
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 293536] kgdb: source code location lookup works for kernel but not for module"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 293536] kgdb: source code location lookup works for kernel but not for module"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 293536] kgdb: source code location lookup works for kernel but not for module"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 293536] kgdb: source code location lookup works for kernel but not for module"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 293536] kgdb: source code location lookup works for kernel but not for module"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 293536] kgdb: source code location lookup works for kernel but not for module"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 293536] kgdb: source code location lookup works for kernel but not for module"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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.