Rust 嵌入二进制大小

我是个新手，在与编译器和借阅检查器进行了多次斗争之后，我终于几乎完成了我的第一个项目。但现在我有一个问题，二进制文件变得越来越大，以适应微控制器的闪存

我用的是STM32F103C8，蓝色药片上有64K闪存。 起初，我能够在mc上安装代码，并且一点一点地启用优化等等。现在，我使用以下工具进行编译：

[profile.dev]
codegen-units = 1
debug = 0
lto = true
opt-level = "z"

我能适应二进制

opt level=“s”

会生成一个大二进制文件。我得到的错误是：

rust lld:error:section'.rodata'将不适合区域“FLASH”：溢出606字节

因为我有不到1000行的代码，而且正如我所说的，这看起来很奇怪

有一些网站喜欢使用最小化二进制文件的方法。因为这些不是嵌入式的，所以大多数最小化的方法都是遵循的

我如何能够最小化二进制大小，并且仍然能够调试它

我的依赖项是：

[dependencies]
cortex-m = "*"
panic-halt = "*"
embedded-hal = "*"

[dependencies.cortex-m-rtfm]
version = "0.4.3"
features = ["timer-queue"]

[dependencies.stm32f1]
version = "*"
features = ["stm32f103", "rt"]

[dependencies.stm32f1xx-hal]
version = "0.4.0"
features = ["stm32f103", "rt"]

可能有一个问题，因为我注意到，

cargo build

在不同版本中多次编译一些子依赖项

在

memory.x文件中：

MEMORY
{
  FLASH : ORIGIN = 0x08000000, LENGTH = 64K
  RAM : ORIGIN = 0x20000000, LENGTH = 20K
}

Rustc版本
Rustc 1.37.0（eae3437df 2019-08-13）

编辑

锈菌恐慌行为中止

代码可以在以下位置查看：
我遇到过类似的问题，可能可以帮助您了解如何减少正在输出的二进制文件的大小

您已经发现了其中一个：
opt level=“z”
。
s
和
z
之间的区别在于内联约束——本质上是编译器认为不值得内联的函数的大小
z
将其指定为25，
s
75。根据您正在构建的内容，这可能会或可能不会导致尺寸的减小（它主要影响
.rodata
和
.text
）

另一件你可以利用的事情是你代码上的
panic
行为。如果我没记错的话，
stm32
目标同时支持
unwind
和
abort
，并且在
dev
配置文件上启用了
unwind
。我相信您可以理解，从代码大小来看，展开堆栈是一个庞大而昂贵的过程。因此，在cargo文件中设置
panic=“abort”
可能会进一步减小二进制大小

除此之外，还需要手动调整，像这样的工具可能非常有用。根据您的使用情况，可能会有一些剩余的
Debug
实现，这些实现只是偶尔需要的，这肯定是您可以采取行动的地方。
其他一些缩小二进制文件的一般技巧：

首先，该实用程序有助于确定二进制文件中哪些内容占用了空间，然后您可以做出明智的决定，如何修改代码以缩小它

其次，通过将编译器配置为，我取得了显著的成功，但是为了更容易调试，没有对顶级机箱进行优化。您可以通过将以下内容添加到Cargo.toml中来完成此操作：

#优化所有依赖项
[profile.dev.package.“*”]
opt level=“z”

如果要调试特定依赖项（例如：cortex-m-rt），可以将其设置为未优化，如下所示：

#不要优化“cortex-m-rt”板条箱
[profile.dev.package.cortex-m-rt]
选择级别=0
#优化所有其他依赖项
[profile.dev.package.“*”]
opt level=“z”
.rodata
表示常量太多/太大，不一定是代码本身太大。但似乎
.rodata
和
.text
共享同一段
FLASH
，因此两者都可能是罪魁祸首。（虽然如果1k LoC Rust生成64kib代码，那么明显的解决方案是不使用Rust…）我目前只创建了5个大小为27的u8数组。虽然我不知道依赖项中使用了哪些常量<代码>arm none eabi size

确实会产生

文本数据bss dec hex

7424 332 112 7868 1ebc

我对Rust的了解几乎不存在，但您应该尝试让链接器生成一个“映射”文件。它将包含所有代码和变量在内存中的位置列表。从那里，你可能会发现一些突出的东西。也许你有大量的软件浮点库链接或类似的东西。STM32F103是，iirc，Cortex M3，因此它没有FPU。为什么要使用宏生成3个不同的模块，这些模块的代码几乎相同，用于访问3个不同的串行端口？这将生成三次代码。恐慌行为设置为中止。当我在没有优化的情况下编译时（并将FLASH设置得更大以便链接器成功）

cargo size

会为

.text

输出

0x13d2e

的大小。因为我只有

0x10000

，所以在任何

.debug*

部件启动之前，这已经太大了。虽然没有调试，

.text

的大小仅为

0x10c3e

。如果我分析nm的输出和链接器的映射文件，我没有发现我不期望的函数调用，尽管我使用的HAL有一些大的调用。也许HAL的依赖性比预期的要大……我对此表示怀疑。你有没有可能把你的整个项目扔到某个地方让我好好看看？听起来你在做一些奇怪的事情，但我无法从你给我的信息中判断我克隆了你的回购协议，通过对依赖项使用opt-level=“z”，我能够使二进制文件符合要求。运行“cargo bloat”表明，您有数百个20-100字节大小的小方法，不确定是什么生成了所有这些方法，但这似乎是缩小二进制大小的成熟场所。谢谢您的回答！这是我第一个生锈的项目。在我无法解决这个问题后，我离开了