查看是否支持符号表

你遇到的这个现象和 Linux 的 `/proc` 文件系统机制有关，下面是详细解释：

---

### 📌 你看到的命令和输出：

```bash
# ls -al /proc/1946/exe
/proc/1946/exe -> /usr/local/bin/kube-controller-manager
```

说明 PID 为 `1946` 的进程的可执行文件是 `/usr/local/bin/kube-controller-manager`。

---

### ❓ 然后你执行了：

```bash
# nm /proc/1946/root/usr/local/bin/kube-controller-manager
nm: /proc/1946/root/usr/local/bin/kube-controller-manager: no symbols
```

你可能想通过 `nm` 来检查该二进制文件是否包含调试符号（符号表），但看到的是「没有符号」，并且疑惑为什么路径是 `root/` 开头。

---

## 🔍 为什么路径是 `/proc/<pid>/root/`？

这个路径代表的是**进程视角下的根目录（/）**。

* `/proc/1946/root` 是进程 1946 所看到的根目录（可能是 chroot 环境）。
* 所以 `/proc/1946/root/usr/local/bin/kube-controller-manager` 表示的是「**进程 1946 所看到的 `/usr/local/bin/kube-controller-manager` 文件**」。

如果该进程没有启用 `chroot`，这个路径其实就是你系统上的 `/usr/local/bin/kube-controller-manager`。

---

## 📌 为什么用 `nm` 看不到符号？

有几个可能的原因：

1. **该二进制被 strip 过了（剥离了符号）**
   这在生产环境中很常见，为了减小体积、提高安全性：

   ```bash
   strip /usr/local/bin/kube-controller-manager
   ```

   会去除符号表（包括函数名、变量名等调试信息），`nm` 就无法读取。

2. **确实编译时未加 `-g` 参数**
   编译时未启用调试信息，也不会生成符号。

你可以验证这点：

```bash
file /proc/1946/root/usr/local/bin/kube-controller-manager
```

如果输出中含有 `stripped`，说明已经去掉了符号表。

---

## ✅ 如何获取符号表？

如果你需要调试信息或符号表，有以下几种方式：

### 1. 重新编译 kube-controller-manager 时加上调试选项：

```bash
go build -gcflags "all=-N -l"
```

或在 Makefile 或构建参数中加入 `-g`。

### 2. 使用带符号的 debug 构建版本

有些 Linux 发行版会发布 `-dbg` 或 `-debuginfo` 包，例如：

```bash
kube-controller-manager-debuginfo.rpm
```

### 3. 使用符号服务器（如 Google 或 Fedora 提供的符号调试源）

---

### 🧠 总结

| 现象                     | 原因                        |
| ---------------------- | ------------------------- |
| `/proc/<pid>/root/` 路径 | 表示进程视角下的根目录               |
| `nm` 提示无符号             | 二进制已被 `strip` 或编译时未加入调试信息 |
| 如何获取符号                 | 使用带符号版本或自行编译带 `-g` 参数的版本  |

如你想进一步调试该进程或做符号关联（如用 `gdb` 或 `perf`），建议获取带符号的二进制文件。需要我提供获取或编译带符号版本的具体步骤也可以告诉我。