我使用 Clang++/LLD 构建了一个非常简单的程序：

然后我运行 readelf 以确认 LLD 确实被用作链接器，如https://releases.llvm.org/11.0.0/tools/lld/docs/index.html所述：

很好，使用的链接器确实是LDD。但这让我想知道为什么那里仍然提到 GCC。也许是因为标准库（大概）是用 GCC 构建的？就是想。

所以我无法找到关于我目前遇到的问题的任何信息。我希望这里有人知道如何解决它。

我正在使用 Clang 11.0.0 编译一个非常简单的 C 程序。我希望它生成一个.pdata包含遵循 Windows 标准的展开信息的部分（参见：https ://docs.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-runtime_function ）。

如果您将其编译为 64 位并使用该-funwind-tables标志。LLD 将以我期望的格式正确生成一个 .pdata 部分。但是如果你将它编译为 32 位 (i686-w64-windows-gnu)，那么它总是会生成一个.eh_fram包含非 Windows 格式的展开信息的部分。

如何告诉 Clang/GCC 或 LLD 也将.pdata样式展开信息用于 32 位编译程序？

有没有办法强制编译器或链接器将 SEH 用于 32 位？

这是我目前测试的：

C代码：

32 位编译段：

64 位编译部分（这.pdata也是我想要的 32 位部分）：

出于研究目的，我正在尝试使用rwpi重定位模型为我的 cortex-m4 微控制器构建图像。但是，在链接阶段，lld 向我抛出错误：

以下是重现此错误的简单方法。这遵循The Embedded Rust Book中的教程。

1. cargo install cargo-generate安装一个方便的工具。
2. cargo generate --git https://github.com/rust-embedded/cortex-m-quickstart下载示例代码。
3. cd进入克隆目录。修改.cargo/config. 添加"-C", "relocation-model=rwpi"到rustflags.
4. 运行cargo build。

中的示例代码main.rs使用了cortex-m-rtcrate，它在编译期间将为链接器生成一个链接脚本。生成的链接脚本可以在./target/thumbv7m-none-eabi/debug/build/cortex-m-rt-xxxxxxxxxxxxxxxx/out/link.x. 我想链接器缺少一些信息。我应该怎么做才能解决问题？

在使用 clang/lld 7 从 Ubuntu 18.04 升级到使用 clang/lld 10 和 boost 1.71 的 1.65 升级到 20.04 后，我遇到了一个我不知道如何解决的链接器错误。已知 Ubuntu 20.04 上的 clang 和 boost 是不兼容的对吗？我有哪些选择可以使用 clang 在 Ubuntu 20.04 上进行编译？

错误的最小示例是

笔记：

• 它适用于 GCC 9 和黄金链接器。
• clang + gold 链接器组合失败并显示非常相同的错误消息，bfd 链接器失败并显示非常短的错误消息，我还将在下面显示输出。
• clang/lld 9 而不是 10 也会出现同样的错误。

我创建了一个可以在 ubuntu 20.04 系统或容器中轻松复制的最小示例，对于我的复制，我使用了ubuntu:focaldockerhub 的普通容器。

1. 安装 clang/lld 10 和 boost 1.71

现在所有要求都已安装，LLD 是默认链接器。

2. 创建最小的示例并编译/链接它

3. 预期结果：

4. 实际结果

• 使用 BFD 链接器（GNU ld 2.34）：

• 使用 LLD 10 作为链接器（但黄金链接器错误看起来非常相似）：

目标：从 ELF 二进制文件中提取完整的程序（合并）后 LTO 位码。

该程序恰好是用 Rust 编写的，但我认为这不是关键的细节。

.llvmbc我可以使用以下 Cargo 调用将 Rust 程序编译为带有部分的 ELF 二进制文件：

然后我可以readelf -S | grep llvmbc用来验证该部分是否存在。确实如此。高超！

我现在想提取完整的程序后 LTO 位码并反汇编它：

如果我在二进制文件中搜索 LLVM 标头的魔术字节，0x4243c0de则有多个命中。此外，如果我告诉rustc使用单个代码生成单元 ( -C codegen-units=1)，那么魔术字节的命中次数就会减少（正好两个）。

我认为正在发生的是链接器.llvmbc将中间对象的部分与后 LTO 位码连接起来，这使llvm-dis.

假设是这种情况，我怎样才能明确地只提取 LTO 后的位码？我对尝试根据魔术字节分离不同的模块感到不舒服。这似乎很容易出错，因为该字节序列可能会巧合地出现在其他地方（即根本不标记位码对象的开始）。

有没有办法让 libLTO 将 LTO 后的位码放入一个不同名称的专用部分？阅读源代码后，我认为没有修改是不可能的。

谢谢

编辑

使用 clang 而不是 rustc 重复实验实际上似乎有效，所以我开始怀疑这是否真的是一个 rust 错误。也许 rustc 在不应该传递旧的预合并位码时传递了它？

我正在尝试在稳定的 Rust 中构建 UEFI 二进制文件，因此我不使用x86_64-unknown-uefi目标，因为它需要 Nightly 工具链。为此，我创建了.cargo/config.toml：

在我的本地机器上构建成功，但在 GitHub Actions ( log ) 上失败。x86_64-w64-mingw32-ld即使我指定lld-link为链接器，仍然使用。

如何强制cargo使用lld-link？

我接近能够在 Windows 上为 Linux 交叉编译二进制文件。我有一个命令可以将我的代码编译为 .o 文件，但我无法将其链接到生成二进制文件。现在它说它无法链接到 Linux 库的多个副本，即使我的系统上有它们的副本并且已将目录提供给链接器。

我使用的命令： clang -fuse-ld=lld -target x86_64-pc-linux-gnu -LD:/Toolchains/Linux/Libs -o main main.o -v

我收到的错误消息是：

所有的cannot open *.o: no such file or directory错误都是我在我的 Windows 机器上有一个副本的文件，所以我不确定从这里去哪里让链接器识别我的文件。当我反向执行此操作时，让链接器识别和使用 Windows 库相对简单

任何帮助将不胜感激

我最近设法在一个大型 cmake 项目中使用了 lld 链接器。（LLVM 11，来自这个包）我不使用 clang，我使用 G++ 和 LLD。

但我遇到以下问题：lld: error: unknown argument: -rpath

按照clang文档，-rpath应该可以工作，至少我猜是clang？

这是cmake生成的g++命令：

我手动尝试了很多组合：

...等，没有任何工作。

据我了解， lld 的行为应该与 ld 完全一样，所以 -Wl,-rpath='$ORIGIN' 应该可以工作吗？我错过了什么 ？

我想知道是否有办法直接从 LLVM IR（包含在 cpp 程序中，即内存中）到共享二进制文件？我正在寻找一种不会在磁盘上创建任何中间文件的方法，除了最终结果，即共享二进制文件。这可能吗？如果是，我在哪里可以找到有关如何操作的文档/参考资料？谢谢！

我有一个使用 gcc 编译并与 lld (LLVM) 链接的项目熟悉这个命令）

我该如何解决？