Master is broken at build-time when SRAM is mapped at an high address

[carlocaione]

This is a regression from v2.5.0.

When trying to compile hello_world using CONFIG_SRAM_BASE_ADDRESS=0x200880000 the compilation fails with:

[1/9] Linking C executable zephyr/zephyr_prebuilt.elf
FAILED: zephyr/zephyr_prebuilt.elf zephyr/zephyr_prebuilt.map 
: && ccache /home/carlo/work/proj/intel/sdk/aarch64-zephyr-elf/bin/aarch64-zephyr-elf-gcc    zephyr/CMakeFiles/zephyr_prebuilt.dir/misc/empty_file.c.obj  -o zephyr/zephyr_prebuilt.elf  -Wl,-T  zephyr/linker_zephyr_prebuilt.cmd  -Wl,-Map=/home/carlo/work/proj/intel/zephyr/zephyr-master/build/zephyr/zephyr_prebuilt.map  -Wl,--whole-archive  app/libapp.a  zephyr/libzephyr.a  zephyr/arch/common/libarch__common.a  zephyr/arch/arch/arm/core/aarch64/libarch__arm__core__aarch64.a  zephyr/arch/arch/arm/core/aarch64/mmu/libarch__arm__core__aarch64__mmu.a  zephyr/lib/libc/minimal/liblib__libc__minimal.a  zephyr/lib/posix/liblib__posix.a  zephyr/drivers/serial/libdrivers__serial.a  -Wl,--no-whole-archive  zephyr/kernel/libkernel.a  zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj  -L"/home/carlo/work/proj/intel/sdk/aarch64-zephyr-elf/bin/../lib/gcc/aarch64-zephyr-elf/10.2.0"  -L/home/carlo/work/proj/intel/zephyr/zephyr-master/build/zephyr  -lgcc  zephyr/arch/common/libisr_tables.a  -mcpu=cortex-a53  -mabi=lp64  -Wl,--gc-sections  -Wl,--build-id=none  -Wl,--sort-common=descending  -Wl,--sort-section=alignment  -Wl,-u,_OffsetAbsSyms  -Wl,-u,_ConfigAbsSyms  -nostdlib  -static  -no-pie  -Wl,-X  -Wl,-N  -Wl,--orphan-handling=warn && cd /home/carlo/work/proj/intel/zephyr/zephyr-master/build/zephyr && /usr/bin/cmake -E echo
/home/carlo/work/proj/intel/sdk/aarch64-zephyr-elf/bin/../lib/gcc/aarch64-zephyr-elf/10.2.0/../../../../aarch64-zephyr-elf/bin/ld:zephyr/linker_zephyr_prebuilt.cmd:59: syntax error
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

[carlocaione]

Result of bisection is:

acda9bf9cec8cc366e5a319f7f35cc234a6e34d3 is the first bad commit
commit acda9bf9cec8cc366e5a319f7f35cc234a6e34d3
Author: Andrew Boie <andrew.p.boie@intel.com>
Date:   Sat Mar 6 17:44:44 2021 -0800

    linker-tool-gcc: revise for MMU support
    
    We need to do a few things differently if we are to support
    a virtual memory map, i.e. CONFIG_MMU where CONFIG_KERNEL_VM_BASE
    is not the same as CONFIG_SRAM_BASE_ADDRESS.
    
     - All sections must be specified with a VMA and LMA, where
       VMA is the virtual address and LMA is the physical memory
       location.
     - All sections must be specified with ALIGN_WITH_INPUT to
       keep VMAs and LMAs synchronized
    
    To do this, the existing linker macros need some adjustment:
    
     - GROUP_LINK_IN undefined when CONFIG_KERNEL_VM_BASE is not
       the same as CONFIG_SRAM_BASE_ADDRESS.
     - New macro GROUP_ROM_LINK_IN for text/rodata sections
     - New macro GROUP_NOLOAD_LINK_IN for bss/noinit sections
     - Implicit ALIGN_WITH_INPUT for all sections
    
    GROUP_FOLLOWS_AT is unused anywhere in the kernel for years
    now and has been removed.
    
    Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
    Signed-off-by: Daniel Leung <daniel.leung@intel.com>

[carlocaione]

Ok, this is not a real problem because this happens only when SRAM_BASE_ADDRESS != KERNEL_VM_BASE that is highly unlikely. I'll prepare anyway a PR to make this more robust.

[nashif]

@dcpleung FYI

[dcpleung]

Ah... CONFIG_KERNEL_VM_BASE gets its value from SRAM in DTS. So if you change CONFIG_SRAM_BASE_ADDRESS, they won't match anymore and thus the issue.

Though, it's weird that CI didn't catch this.

[carlocaione]

Though, it's weird that CI didn't catch this.

I opened #33631 to try to catch this in CI