减小.rodata的大小

Reducing the size of .rodata

本文关键字：rodata 减小      更新时间：2023-10-16

我在Gentoo中为ARM Cortex M3 (Maple Mini)交叉编译c++，但在链接self -file

时，似乎遇到了内存资源的屋顶
/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内容的大小，以便能够完成self -file的链接。

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

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

不过，映射文件中的.rodata(我对它很不熟悉)似乎包含了程序中每个类的某种类型信息。一些地图文件摘录(注。MPU6050是一个SuperSensor<>，它是一个传感器<>，在c++的意义上)

    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部分，以及那里究竟存储了什么?欢迎提出任何建议!我对编译和链接的深层工作相当陌生，但正在学习。

我认为你的问题可能不一定是在rodata部分，而是在muscal chairs事件中没有及时坐下的那个家伙。换句话说，rodata本身并不是太大，而是整个IMAGE太大而无法适应。解决方案是查看系统中的整个代码、数据和rodata，看看其中是否有什么特别之处。

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

潜在的问题不是.rodata部分太大，这是必然的——你只是用完了一般的ROM空间。(链接器恰好在链接该部分时达到了限制)

删除对perror, strerror和company等函数的任何调用应该最终放弃对strerror.o的依赖，这应该为您节省1.5 kb的内存。不过，也许还有其他更简单的方法可以节省同样的费用——这完全取决于您的应用程序。

相关文章：