Cannot step into system call source code

You appear to have fundamental lack of understanding of how UNIX systems work.

Think about it. Suppose you were able to step into the kernel function that implements a system call, say sys_open. So now you are looking at the kernel source for sys_open in the debugger. The question is: is the kernel running at that point, or is it stopped. Since you will want to do something like next in the debugger, let's assume the kernel is stopped.

So now you press the n key, and what happens?

Normally, the kernel will react to an interrupt raised by the keyboard, figure out which key was pressed, and send that key to the right process (the one that is blocked in read(2) from the terminal that has control of the keyboard).

But your kernel is stopped, so no key press for you.

Conclusion: debugging the kernel via debugger that is running on that same machine is impossible.

In fact, when people debug the kernel, they usually do it by running debugger on another machine (this is called remote debugging).

If you really want to step into kernel, the easiest way to do that is with UML.

After you've played with UML and understand how the userspace/kernel interface works and interacts, you can try kgdb, though the setup is usually a bit more complicated. You don't actually have to have a separate machine for this, you could use VMWare or VirtualPC, or VirtualBox.

As Employed Russian already stated, gdb being in userland cannot inspect anything running in the kernel.

However, nothing prevents to implement a debugger in the kernel itself. In such case, it is possible to set breakpoints and run kernel code step by step from a local debugging session (console). With FreeBSD, such a debugger is available as ddb.

Some limitations would be the lack of connection between your gdb and ddb sessions and I'm unsure source level debugging (-g) is available for kernel code under FreeBSD/ddb.

An alternate and much less intrusive way to 'debug' the kernel from userland would be to use dtrace.