链接描述文件总是将变量解释为零吗?

时间:2019-12-10 05:27:15

标签: gcc linker arm embedded zephyr-rtos

下面有很多日志和其他内容,因此跳至重点:我有一个链接描述文件,并且正在其中设置变量,并使用这些变量来设置内存部分。但是无论我在脚本中将这些变量设置为什么,这些变量似乎总是被设置为0。

我正在编写一个链接描述文件,试图为嵌入式系统应用程序的输出elf添加两个新的内存部分。我正在尝试砍掉预先存在的RAM内存部分的第一部分,相应地更改RAM的大小,然后将新的部分放在那儿。

以前,使用nrf52840开发板和this库,我可以这样修改示例应用程序之一的链接脚本:

SEARCH_DIR(.)
GROUP(-lgcc -lc -lnosys)

__NewSection1Start  = 0x20000000;
__TotalLength = 0x1000;
__NewSection2Length = __TotalLength / 2;
__NewSection1Length = __TotalLength / 2;
__NewSection2Start = __NewSection1Start + __NewSection1Length;

MEMORY
{
  FLASH (rx)           : ORIGIN = 0x0,         LENGTH = 0xff000
  NEWSECTION1 (rwx) : ORIGIN = __NewSection1Start, LENGTH = __NewSection1Length
  NEWSECTION2 (rwx) : ORIGIN = __NewSection2Start, LENGTH = __NewSection2Length
  RAM (rwx)            : ORIGIN = 0x20000000 + __TotalLength, LENGTH = 0x40000 
}

FLASH_PAGE_SIZE       = 4096;
FLASH_DATA_PAGES_USED = 4;

SECTIONS
{
  .newsection1 :
  {
    KEEP (*(.newsection1));
  } > NEWSECTION1
  .newsection2 :
  {
    KEEP (*(.newsection2));
  } > NEWSECTION2
}
...

这很好用。最近,我需要使用Zephyr RTOS移植到nrf9160,因此我开始使用在this链接的Zephyr之上构建的NordicPlayground nrf库,在那里修改了其中一个示例应用程序。在尝试使用类似于this的技术为该主板和环境重写程序时,我对Zephyr链接程序脚本做了类似的操作,并像以前一样对其进行了修改。构建过程以某种方式采用了我所做的事情,并在构建输出文件夹中生成文件build/spm/zephyr/linker.cmd

__TotalLength = 0x1000;
__NewSection1Start = 0x20000000;
__NewSection2Length = __TotalLength / 2;
__NewSection1Length = __TotalLength / 2;
__NewSection2Start = __NewSection1Start + __NewSection1Length;
MEMORY
    {
    FLASH (rx) : ORIGIN = 0x0, LENGTH = 0xc000
    SRAM (wx) : ORIGIN = 0x20000000 + __TotalLength, LENGTH = (64 * 1K) - __TotalLength
    NEWSECTION1 (rwx) : ORIGIN = __NewSection1Start, LENGTH = __NewSection1Length
    NEWSECTION2 (rwx) : ORIGIN = __NewSection2Start, LENGTH = __NewSection2Length
    IDT_LIST (wx) : ORIGIN = (0x20000000 + (64 * 1K)), LENGTH = 2K
    }
ENTRY("__start")
SECTIONS
{
  .newsection1 :
  {
    KEEP (*(.newsection1));
  } > NEWSECTION1
  .newsection2 :
  {
    KEEP (*(.newsection2));
  } > NEWSECTION2
}
...

但是,尽管我认为这两个脚本应具有相同的行为,但尝试使用Zephyr RTOS编译并链接到nrf9160版本会引发此错误:

riley@riley-Blade:~<code_base>/nrf/samples/nrf9160/example_app$ west build -b nrf9160_pca10090ns
source directory: /home/riley<code_base>/nrf/samples/nrf9160/example_app
build directory: /home/riley<code_base>/nrf/samples/nrf9160/example_app/build
BOARD: nrf9160_pca10090ns (origin: CMakeCache.txt)
[6/17] Linking C executable spm/zephyr/spm_zephyr_prebuilt.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:         32 KB        48 KB     66.67%
            SRAM:       10000 B        60 KB     16.28%
  NEWSECTION1:          0 GB         2 KB      0.00%
  NEWSECTION2:          0 GB         2 KB      0.00%
        IDT_LIST:          40 B         2 KB      1.95%
[12/17] Linking C executable zephyr/zephyr_prebuilt.elf
FAILED: zephyr/zephyr_prebuilt.elf 
: && ccache /home/riley/gcc-arm-none-eabi-9-2019-q4-major/bin/arm-none-eabi-gcc    zephyr/CMakeFiles/zephyr_prebuilt.dir/misc/empty_file.c.obj  -o zephyr/zephyr_prebuilt.elf  -Wl,-T zephyr/linker.cmd -Wl,-Map=/home/riley<code_base>/nrf/samples/nrf9160/example_app/build/zephyr/zephyr.map -u_OffsetAbsSyms -u_ConfigAbsSyms -Wl,--whole-archive app/libapp.a zephyr/libzephyr.a zephyr/arch/arm/core/libarch__arm__core.a zephyr/arch/arm/core/cortex_m/libarch__arm__core__cortex_m.a zephyr/arch/arm/core/cortex_m/mpu/libarch__arm__core__cortex_m__mpu.a zephyr/lib/libc/minimal/liblib__libc__minimal.a zephyr/subsys/net/libsubsys__net.a zephyr/subsys/net/ip/libsubsys__net__ip.a zephyr/drivers/gpio/libdrivers__gpio.a zephyr/drivers/serial/libdrivers__serial.a zephyr/modules/nrf/lib/bsdlib/lib..__nrf__lib__bsdlib.a zephyr/modules/nrf/lib/at_host/lib..__nrf__lib__at_host.a zephyr/modules/nrf/drivers/at_cmd/lib..__nrf__drivers__at_cmd.a /home/riley<code_base>/nrfxlib/bsdlib/lib/cortex-m33/hard-float/libbsd_nrf9160_xxaa.a -Wl,--no-whole-archive zephyr/kernel/libkernel.a zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj -L"/home/riley/gcc-arm-none-eabi-9-2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/thumb/v8-m.main+fp/hard" -L/home/riley<code_base>/nrf/samples/nrf9160/example_app/build/zephyr -lgcc -Wl,--print-memory-usage /home/riley<code_base>/nrfxlib/crypto/nrf_oberon/lib/cortex-m33/hard-float/liboberon_3.0.0.a -lc -mthumb -mcpu=cortex-m33 -mfpu=fpv5-sp-d16 -Wl,--gc-sections -Wl,--build-id=none -Wl,--sort-common=descending -Wl,--sort-section=alignment -nostdlib -static -no-pie -Wl,-X -Wl,-N -Wl,--orphan-handling=warn -mabi=aapcs -march=armv8-m.main+dsp libspmsecureentries.a && :
Memory region         Used Size  Region Size  %age Used
           FLASH:      110428 B       976 KB     11.05%
            SRAM:       24608 B       124 KB     19.38%
  NEWSECTION1:         264 B         0 GB       inf%
  NEWSECTION2:           1 B         0 GB       inf%
        IDT_LIST:         120 B         2 KB      5.86/home/riley/gcc-arm-none-eabi-9-2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld: zephyr/zephyr_prebuilt.elf section `.newsection1' will not fit in region `NEWSECTION1'
/home/riley/gcc-arm-none-eabi-9-2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld: zephyr/zephyr_prebuilt.elf section `.newsection2' will not fit in region `NEWSECTION2'
/home/riley/gcc-arm-none-eabi-9-2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld: section .newsection2 LMA [0000000000000000,0000000000000000] overlaps section .newsection1 LMA [0000000000000000,0000000000000107]
/home/riley/gcc-arm-none-eabi-9-2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld: region `NEWSECTION1' overflowed by 264 bytes
/home/riley/gcc-arm-none-eabi-9-2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld: region `NEWSECTION2' overflowed by 1 byte
collect2: error: ld returned 1 exit status
%
ninja: build stopped: subcommand failed.
ERROR: command exited with status 1: /home/riley/.local/bin/cmake --build /home/riley<code_base>/nrf/samples/nrf9160/example_app/build

这对我来说真的很奇怪,因为这个输出使NEWSECTION1NEWSECTION2的长度看起来像0,并且都从地址0x0开始,但是绝对不应该这样查看使用的链接描述文件。更令人困惑的是,如果我将__NewSection1Length替换为0x500或类似的内容,则内存段的长度为0x500B,这意味着错误似乎在于使用变量在此链接描述文件中被忽略还是设置为0?任何帮助将不胜感激。

1 个答案:

答案 0 :(得分:0)

Zephyr的一些更复杂的功能(例如引导程序和SPM(安全分区管理器))实际上是使用独立的板定义,链接程序脚本和项目配置来构建的。即使它们全部发生在一次调用west buildninjamake或您配置了任何构建工具的情况下,它们有时仍会失配。

如果进入构建输出目录,您会看到此信息,请注意将有多个子目录,它们的名称分别为spmmcubootzephyr。这些子目录中的每一个都将包含它们自己的目标文件,映射文件,链接脚本等。zephyr目录是顶层目录,其中包含最终应用程序的构建/链接工作,并将合并到编译其他二进制文件。我认为正在发生的事情是,您为在应用程序中创建自定义部分所做的prj.conf更改仅影响这些子内部版本中的一个。您可能需要查找其他文件的prj.conf文件,并进行类似的修改。