Linux – Does the kernel itself depend on the standard C libraries

Libgcc is even more fundamental than libc. Libgcc contains code that is used by the GCC compiler when generating code for fundamental language constructs, such as 64-bit arithmetic on 32-bit platforms, stack maintenance, integers and floating point operations that the hardware doesn't perform, etc.

Debian's gcc-base package contains only a couple of symbolic links and a few documentation files for libgcc.

You can't remove these packages, even if you never compile anything, because they aren't here to compile stuff. They are not for running GCC, they are for running software compiled with GCC.

When you update the kernel, you actually update the kernel package. On most Linux distributions, what this really does is just register the package in your package manager, add the new modules under /lib/modules, add the initramfs and kernel under /boot, and maybe update the bootloader entries and some other miscellaneous activity. It doesn't generally actually replace the loaded kernel in memory.

At boot, the kernel itself is loaded into memory. That is, even if the file it was loaded from (eg. /boot/vmlinuz) goes away, it's not needed after initial loading of the kernel.

Even if it was needed for something (say, debugging information) and has been replaced, anyone already with an open file handle to it will still be able to use the file, since the backing data won't be deleted until the inode in question has a reference count of 0 (the kernel itself doesn't need such a reference though, since it's already loaded into memory, unlike running processes from userspace executables). Those blocks normally can be fully freed from disk unless you're in the middle of running some user-space program on that file. The Linux kernel doesn't page its own memory, and even decompresses itself on the fly at startup. There's no /proc/.../exe or /proc/.../fd way to access the booted /boot/vmlinuz — the kernel might not even mount the device it was booted from in a netboot or USB-boot situation.

So generally, the kernel doesn't update itself. That's typically done at reboot or kexec time. The kind of thing you're describing does exist for limited use cases as kpatch, kgraft, and ksplice, but generally these can only be used for small and targeted patches, not new upstream kernel releases.