@yanqiyu 感谢回复
我试了一下，关闭 kaslr 后通过查看 /proc/iomem 发现内核代码的起始地址固定是在物理内存 16MB （ qemu ）或 32MB （物理机），不明白为什么不是在 2MB 。

@kgdb00 #2 更正：一个页框 -> 一组页框

@2i2Re2PLMaDnghL 感谢回复
https://www.kernel.org/doc/html/latest/x86/boot.html 这个文档讲物理地址 0x100000 以上是 Protected-mode kernel ，意思应是内核代码的物理地址在从 2MB 开始的区域，我猜测内核函数的物理地址随机化之后应该也是在靠近 2MB 的位置，不太可能是整个物理内存完全随机，因为那样的话就不好分配一个很大的物理地址连续的页框，不知道我猜的对不对。

“但是我老婆的学习方式是看书，明白原理再去推演使用”

你老婆适合学 linux 内核，先从 intel 的处理器架构程序员编程指南开始看，先看懂硬件再去搞软件

#32 一插上就识别成百兆

借楼问一下，其他牌子有那种超细的 6 类线吗？

我买的网线几乎全都是山泽的，主要因为只有他们家有那种超细的网线，方便理线，不过质量是真的不行，我都买到过 3 跟有质量问题的细网线，都是导致千兆网络被识别成百兆，他们家的 7 类扁平网线我也买过，结果也把我坑大了，当时我用这根网线直连两台台式机的 2.5G 板载网卡，结果 dmesg 一直报各种网络异常的日志，我还以为是 linux 驱动的问题，排查了好久，最后换根网线解决问题。

@kgdb00 报的错如下：
ld: /lib64/libc.a(iofclose.o): in function `_IO_new_fclose.cold':
(.text.unlikely[.text.unlikely.group]+0x33): undefined reference to `_Unwind_Resume'
ld: /lib64/libc.a(iofclose.o):(.data.rel.local.DW.ref.__gcc_personality_v0[DW.ref.__gcc_personality_v0]+0x0): undefined reference to `__gcc_personality_v0'
ld: /lib64/libc.a(iofflush.o): in function `_IO_fflush.cold':
(.text.unlikely[.text.unlikely.group]+0x32): undefined reference to `_Unwind_Resume'
ld: /lib64/libc.a(wfileops.o): in function `_IO_wfile_underflow.cold':
(.text.unlikely[.text.unlikely.group]+0x3d): undefined reference to `_Unwind_Resume'
ld: /lib64/libc.a(fileops.o): in function `_IO_new_file_underflow.cold':
(.text.unlikely[.text.unlikely.group]+0x33): undefined reference to `_Unwind_Resume'
ld: /lib64/libc.a(printf_fp.o): in function `__printf_fp_l':
(.text+0x53f): undefined reference to `__unordtf2'
ld: (.text+0x585): undefined reference to `__unordtf2'
ld: (.text+0x5ab): undefined reference to `__letf2'
ld: /lib64/libc.a(printf_fphex.o): in function `__printf_fphex':
(.text+0xa6): undefined reference to `__unordtf2'
ld: (.text+0xd9): undefined reference to `__unordtf2'
ld: (.text+0xf6): undefined reference to `__letf2'
ld: /lib64/libc.a(iofputs.o): in function `_IO_fputs.cold':
(.text.unlikely[.text.unlikely.group]+0x32): undefined reference to `_Unwind_Resume'
ld: /lib64/libc.a(iofwrite.o): in function `_IO_fwrite.cold':
(.text.unlikely[.text.unlikely.group]+0x32): undefined reference to `_Unwind_Resume'
ld: /lib64/libc.a(iogetdelim.o): in function `__getdelim.cold':
(.text.unlikely[.text.unlikely.group]+0x32): undefined reference to `_Unwind_Resume'
ld: /lib64/libc.a(pthread_once.o): in function `__pthread_once_slow.cold':
(.text.unlikely[.text.unlikely.group]+0x25): undefined reference to `_Unwind_Resume'

@lcdtyph 试了，不行，和没加这两个参数效果一样，去掉 /usr/lib/gcc/x86_64-redhat-linux/11/libgcc.a 和 /usr/lib/gcc/x86_64-redhat-linux/11/libgcc_eh.a 后报的错一样。

@kgdb00 #5 "-m elf_x86_64 -static"这两个参数也不是必要的，以下命令就能完全静态链接一个 hello world 的 c 程序。

ld /usr/lib64/crt1.o /usr/lib64/crti.o main.o \
--start-group \
/lib64/libc.a \
/usr/lib/gcc/x86_64-redhat-linux/11/libgcc.a \
/usr/lib/gcc/x86_64-redhat-linux/11/libgcc_eh.a \
--end-group \
/usr/lib64/crtn.o

@secondwtq
对，以下是精简过的 gcc 传给 ld 的参数，这条命令可以链接成功，不过我不想依赖 libgcc.a 和 libgcc_eh.a 这两个库，但去掉就链接不通过，难道 gnu c 库静态链接非得和编译器的库绑定在一起? 动态链接的时候是不需要 gcc 的库的。

/bin/ld -m elf_x86_64 -static /usr/lib64/crt1.o /usr/lib64/crti.o main.o \
--start-group \
/lib64/libc.a \
/usr/lib/gcc/x86_64-redhat-linux/11/libgcc.a \
/usr/lib/gcc/x86_64-redhat-linux/11/libgcc_eh.a \
--end-group \
/usr/lib64/crtn.o

@ysc3839 可以静态链接的，fedora 上有一个 glibc-static 包，这个包有一个 /usr/lib64/libc.a 文件，就是 glibc 的静态库

ld 能静态链接一个普通的用户库，比如 foo.o 或 libfoo.a ，我想知道的是如何静态链接 gnu c 库。

我估计贵公司主要的业务是给大客户做定制的产品，就是不知道贵公司定制的产品是笔记本或平板电脑形态，还是 Raspberry Pi 这种需要外接显示器的形态？
如果是后者，那我觉得挺尴尬的，因为这样用就失去了便携性，对于需要批量低成本设备的客户，还不如用云桌面，反正都是固定在一个地方使用，用 windows 软件生态还会更好一些，而且 windows 又不是不付费就没法用。

@HamGuy 我都不用 exsi

@geekvcn lxc 也能直通显卡吗？那是不是也可以直通 usb ，然后当作做桌面机来用？希望老哥给发个教程

@hhjuteman 我就用 C/C++ GNU Global 插件得了，不折腾了。

@hhjuteman clangd 插件试了一下，发现了一个很严重的 bug ，我有多个内核的源码目录，checkout 不同的版本，结果跳转时会跳转到其他内核目录的对应文件。
而且还不能关闭语法检查，一大堆报错看着难受。
而且这个插件使用人数太少，估计还有不少其他 bug 。