Handle multiple RAM regions

[MathiasKoch]

Currently this only checks for overflows in single-ram region called RAM.

Eventually it would be awesome to support multi region layouts like:

MEMORY
{
    RAM             : org = 0x20000000, len = 96k      /* SRAM1 */
    RAM2            : org = 0x10000000, len = 32K      /* SRAM2 */
}

The "line-by-line" parser only looks for RAM: org = ..., but I am not sure if this is the actual blocker?

Also minor side issue;
This line:

flip-link/src/main.rs

Line 61 in e123f17

bail!("MEMORY.RAM found after scanning linker scripts");

Should probably read MEMORY.RAM not found after scanning linker scripts ? Missing the not

[japaric]

Eventually it would be awesome to support multi region layouts like:

What kind of layout do you have in mind? For instance, if you place the stack in RAM2 and the rest of sections in RAM then already have stack overflow protection and flip-link should be a no-op.

This definitively seems doable but we need to list the potential arrangements of stack, static variables and heap. Also more than 2 RAM regions seems possible though I'm not sure cortex-m-rt supports that particularly well.

[japaric]

if you place the stack in RAM2 and the rest of sections in RAM then already have stack overflow protection and flip-link should be a no-op.

if we rely solely on standard sections like .bss and .data we may miss the cases where the user puts a custom section (.my_section) in RAM2 -- that could result in a collision. Perhaps we should look at the addresses of symbols instead of at the sections in that (2 RAM regions) case?

[MathiasKoch]

Ohh

You are totally right! I was waaay to fast on an early monday morning! Totally forgot we are only talking about stack. Please disregard this issue! Feel free to close.

[japaric]

I'm going to leave this open because I think we want to "support" at least the 2 RAM region configuration. By support I mean flip-link should not error and panic and it should produce a binary that won't result in memory corruption due to stack overflow (even if that means doing nothing = linking normally).
Also, I'm not sure what the behavior is in the 2 RAM regions case; that's an scenario I haven't really tested.

[MathiasKoch]

In my case i am using both ram regions, but only for static queues and buffers:

#[init(None)]
#[link_section = ".ram2"]
res_queue: Option<ResQueue<AtatRxBufLen, consts::U5>>,
#[init(None)]
#[link_section = ".ram2"]
urc_queue: Option<UrcQueue<AtatRxBufLen, consts::U10>>,
#[init(None)]
#[link_section = ".ram2"]
com_queue: Option<ComQueue<consts::U3>>,

// Cellular Socket Buffer
#[init(None)]
#[link_section = ".ram2"]
socket_set: Option<SocketSet<consts::U2, consts::U2048>>,