Memory的布局如何管理？

Question

我想稳健地管理我的 linker 脚本。 我喜欢让我的一些 bss 和数据部分靠近代码源的想法。 例如，我想要大约 4 或 5 个部分（引导程序、kernel、os 等）。 手动管理长度开始变得乏味。

MEMORY
{
    boot : ORIGIN = 0x20000000, LENGTH = 0x0010
    table : ORIGIN = 0x20000011, LENGTH = 0xE1C
    os : ORIGIN = 0x20000E1D, LENGTH = 0x00B0
}
SECTIONS
{
    .text : { *(.text) } > boot
    .table : { *(.rodata) } > table
    .os : { *(.os) } > os
}

这应该暗示我正在尝试解决我的问题。 每次我进行任何代码更改时，我都需要构建 .o 文件，然后列出反汇编以获得最后的指令值并添加 4 个字节，然后修改我的 memmap 文件中的所有长度。 这是相当乏味的。

你可以看到我在下面工作的那个，但给我的控制更少。

MEMORY
{
    os : ORIGIN = 0x20000000, LENGTH = 0x00B0
    table : ORIGIN = 0x20001000, LENGTH = 0xE1C
}
SECTIONS
{
    .text : { *(.text) } > os
    .table : { *(.rodata) } > table
}

这里的问题是我真的很想控制布局，使表格靠近引导扇区，然后启动 os 部分，然后它的 bss 或 rodata 也可以靠近 os 部分进行管理。 我想这样做是因为为不同的硬件设备提供单独的 linker 脚本会很好，而且我只需换出不同的文件即可管理它们的布局。

是否有更好的策略来管理 memory 布局？

以下是代码的基础知识。

靴子

.section .text

.extern _vizoros
_boot:
    # Few other things before jal.
    j _vizoros

表.s

.section .rodata
.align 4
.string "wot","sar","eon","lig","beg","not","yes","act"
# 2700 total bytes of unique three letter words.

操作系统

.section .text
.balign 4
.globl _vizoros
_vizoros:
    # os begins.