Open
Description
I have a memory.x file like this:
MEMORY
{
FLASH : ORIGIN = 0x00000000, LENGTH = 256K
/* RAM is a mandatory region. This RAM refers to the SRAM_0 */
RAM : ORIGIN = 0x1FFF8000, LENGTH = 32K
SRAM_1 : ORIGIN = 0x20000000, LENGTH = 32K
}
/* This is where the call stack will be allocated. */
/* The stack is of the full descending type. */
/* NOTE Do NOT modify `_stack_start` unless you know what you are doing */
/* SRAM_0 can be used for all busses: Instruction, Data and System */
/* SRAM_1 only supports the system bus */
_stack_start = ORIGIN(RAM) + LENGTH(RAM);
/* Define sections for placing symbols into the extra memory regions above. */
/* This makes them accessible from code. */
SECTIONS {
.sram1 (NOLOAD) : ALIGN(8) {
*(.sram1 .sram1.*);
. = ALIGN(4);
} > SRAM_1
};Basically, I have two adjacent SRAM segments, but only the first one can be used for .data/.bss stack etc.
When I use flip-link to generate my applications, weird things happen and my app crash on startup.
I enabled debug printout for the flip link generation:
[INFO flip_link] found MemoryEntry(line=4, origin=0x1fff8000, length=0x8000) in /home/rmueller/Rust/va416xx-rs/memory.x
[INFO flip_link] used RAM spans: origin=0x1fff8000, length=32768, align=8
[INFO flip_link] new RAM region: ORIGIN=0x1fff8000, LENGTH=32768
INFO rustc_codegen_ssa::back::link linker stdout:
Finished `dev` profile [unoptimized + debuginfo] target(s) in 5.07s
so that definitely looks weird. When I remove the . = ALIGN(4), it looks more correct
[INFO flip_link] found MemoryEntry(line=4, origin=0x1fff8000, length=0x7ff8) in /home/rmueller/Rust/va416xx-rs/memory.x
[INFO flip_link] used RAM spans: origin=0x1fff8000, length=1088, align=4
[INFO flip_link] new RAM region: ORIGIN=0x1ffffbb8, LENGTH=1088
INFO rustc_codegen_ssa::back::link linker stdout:
Finished `dev` profile [unoptimized + debuginfo] target(s) in 5.12s
and those apps also run properly.
I saw those alignment calls in multiple linker scripts.. Can they be possibly problematic and confuse flip-link?
Metadata
Metadata
Assignees
Labels
No labels