c++ - 减小 .rodata 的大小

Question

我正在 Gentoo 中为 ARM Cortex M3 (Maple Mini) 交叉编译 C++，但在链接 elf 文件时似乎遇到了内存资源问题

/usr/libexec/gcc/arm-none-eabi/ld: build/maple_mini.elf section `.rodata' will not fit in region `rom'
/usr/libexec/gcc/arm-none-eabi/ld: region `rom' overflowed by 1508 bytes

这个帖子是关于如何减小.rodata 内容的大小，从而能够完成elf 文件的链接的问题。

我已经剥离了包含的代码，并且正在使用以下相关选项进行编译。

CXXFLAGS = -fno-rtti -fno-exceptions -Os -fdata-sections -ffunction-sections -Wl,-gc-sections ...
LDFLAGS = -Wl,-gc-sections -fno-exceptions -fno-rtti ...

不过，映射文件(我对它相当陌生)中的 .rodata 似乎包含程序中每个类的某种类型信息。一些 map 文件摘录(注意。MPU6050 是一个 SuperSensor<>，在 C++ 意义上是一个 Sensor<>)

    0x000000000801d6c0       0x28 .../libsyrup.a(MPU6050.o)
    0x000000000801d6c0    _ZTVN5syrup6SensorILi6EEE
.rodata._ZTVN5syrup11SuperSensorILi6EEE    0x000000000801d6e8       0x28 .../libsyrup.a(MPU6050.o)
    0x000000000801d6e8                _ZTVN5syrup11SuperSensorILi6EEE
.rodata._ZTVN5syrup7MPU6050E  0x000000000801d710       0x28 .../libsyrup.a(MPU6050.o)
     0x000000000801d710                _ZTVN5syrup7MPU6050E
.rodata._ZTVN5syrup6SensorILi1EEE
     0x000000000801d738                 0x28 .../libsyrup.a(MS5611.o)
     0x000000000801d738                _ZTVN5syrup6SensorILi1EEE
.rodata._ZTVN5syrup11SuperSensorILi1EEE
            0x000000000801d760          0x28 .../libsyrup.a(MS5611.o)
            0x000000000801d760                _ZTVN5syrup11SuperSensorILi1EEE
...
            0x000000000801ee24          0x6f3 .../libstdc++.a(cp-demangle.o)
                                        0x730 (size before relaxing)
*fill*         0x000000000801f517       0x1 
.rodata        0x000000000801f518       0x14 .../libgcc.a(unwind-arm.o)
.rodata        0x000000000801f52c       0x23c .../libc.a(lib_a-strerror.o)
.rodata.str1.4    0x000000000801f768    0x635 .../libc.a(lib_a-strerror.o)
                                        0x63c (size before relaxing)

所以， lib_a-strerror.o和 cp-demangle.o似乎是占用最多空间的内容，尽管我猜这些内容非常重要。

所以，我的问题是，我可以采取哪些进一步的步骤来减少(或重组代码).rodata 部分，以及那里到底存储了什么？欢迎任何建议!我对编译和链接的更深层工作还很陌生，但正在学习。

Answer 1

我认为您的问题不一定出在 rodata 部分 - 只是那个人没有在音乐椅事件中及时坐下来。换句话说，不是rodata本身太大，而是WHOLE IMAGE太大放不下。解决方案是查看系统中的整个代码、数据和 rodata，看看是否有任何突出显示。

一般来说，删除不必要的代码(或字符串)将是这里的关键点。如果没有可以删除的东西，那么您将不得不找到其他方法来解决问题。一种方法可能是压缩代码和数据，然后将其解压缩到 RAM 中(假设目标系统上的 RAM 比 ROM 多得多)。这不是一个闻所未闻的问题，但它从来没有真正那么容易修复——除非有人做了一些非常糟糕的编码并添加了数百 KB 的代码。如果你有一个版本控制系统，并且你知道一个适合的版本，那么检查到底有多少空闲空间可能是一件好事 - 如果它突然增长了很多，检查是否有人添加了一些大量的静态数据结构或类似的东西。