Exercises — Linker scripts — memory regions, sections (.text, .data, .bss)

• (a) .data — non-zero value se initialized, toh value $42$ ko store karna padega (Flash mein) aur RAM mein copy karna padega.
• (b) .bss — koi initializer nahi wala global implicitly zero hota hai, toh yeh .bss mein jaata hai (sirf uski size record hoti hai).
• (c) .rodata — const data read-only hai, Flash mein rakha jaata hai.
• (d) .text — machine code hamesha Flash mein rehta hai aur wahan se execute hota hai.
• (e) .bss — yeh trap hai. Yeh 0 se initialized hai, aur zero-initialized data .bss mein jaata hai, .data mein nahi (Flash mein zeros store karna wasteful hoga). Neeche mistake dekho.

• ADDR(.data) → VMA (run address, RAM mein).
• LOADADDR(.data) → LMA (load address, Flash mein, jahaan init values physically baithe hain).
• SIZEOF(.data) → .data mein kitne bytes hain.

Parent se memory hook: Data Doubles — do addresses. Figure 1 mein yeh do amber blocks hain.

(a) Flash image. Image mein physically sab kuch hona chahiye jo power-off survive kare: code, read-only constants, aur .data ke initial values (uski LMA copy — Figure 1 mein amber Flash block). .bss Flash mein kuch nahi contribute karta. $\text{Flash}=12000+2048+500=14548\text{ bytes}$ (b) RAM. Static RAM mein .data (copy hone ke baad) plus .bss hota hai: $\text{RAM}=500+4096=4596\text{ bytes}$ Note karo .data dono budgets mein count hota hai — uske do ghar hain, exactly LMA/VMA idea.

Location counter . yaad karo (upar define kiya): yeh cursor hai jo region ke ORIGIN se shuru hota hai aur har section ki size ke barabar aage badhta hai. Flash mein yeh $O_{FLASH}=\text{0x08000000}$ se shuru hota hai. (a) .text (0x2FEC bytes) place hone ke baad, cursor 0x2FEC se aage badh gaya, toh .data wahan load hota hai: $\text{LOADADDR(.data)}=\text{0x08000000}+\text{0x2FEC}=\text{0x08002FEC}$ (b) .data (0x200 bytes) ke baad cursor phir aage badhta hai: $\text{0x08002FEC}+\text{0x200}=\text{0x080031EC}$

Pointers uint32_t* hain, toh q++ har iteration mein 4 bytes advance karta hai (Figure 2 mein ek arrow per word). (a) RAM mein byte span $=\text{0x20000010}-\text{0x20000000}=\text{0x10}=16$ bytes. Words: $16/4=4\text{ words}$ (b) Flash pointer p 0x08002FEC se shuru hota hai aur 4 se step karta hai: $\text{0x08002FEC},\text{0x08002FF0},\text{0x08002FF4},\text{0x08002FF8}$ (char reads, 0x20000000, 04, 08, 0C pe char writes se match karte hain — Figure 2 mein char arrows).

1. Garbage collection koi bhi section delete kar deta hai jo kisi symbol ke dwara referenced nahi hai — Flash bachane ke liye.
2. .isr_vector section (vector table) C mein kabhi naam se call nahi hota — CPU ise hardware convention se Flash ke base se padhta hai. Linker ko koi reference nahi dikhta.
3. Toh GC .isr_vector drop kar deta hai. Ab Flash ke pehle bytes woh section hai jo wahan aakar baith gaya (ya padding).
4. Reset pe CPU initial stack pointer aur Reset_Handler address (ab missing) vector table se load karna chahta hai → garbage addresses → immediate hard fault. KEEP() linker ko kehta hai "pretend karo yeh referenced hai; ise kabhi collect mat karo."

"vector table, phir .text, phir .rodata" ko distinct, ordered sections ke roop mein honour karne ke liye, hum har ek ko uska apna output section dete hain .rodata ko .text mein fold karne ke bajaye. File mein unka order wahi order hai jisme woh Flash mein place hote hain.

MEMORY
{
  FLASH (rx)  : ORIGIN = 0x08000000, LENGTH = 256K
  RAM   (rwx) : ORIGIN = 0x20000000, LENGTH = 64K
}
 
SECTIONS
{
  .isr_vector : {
    . = ALIGN(4);
    KEEP(*(.isr_vector))   /* vector table FIRST; KEEP survives GC */
    . = ALIGN(4);
  } > FLASH
 
  .text : {
    . = ALIGN(4);
    *(.text*)              /* machine code */
    . = ALIGN(4);
  } > FLASH
 
  .rodata : {
    . = ALIGN(4);
    *(.rodata*)            /* read-only constants, kept separate */
    . = ALIGN(4);
  } > FLASH
 
  _sidata = LOADADDR(.data);   /* Flash source of init values (LMA) */
  .data : {
    . = ALIGN(4);
    _sdata = .;                /* RAM run start (VMA) */
    *(.data*)
    . = ALIGN(4);
    _edata = .;                /* RAM run end */
  } > RAM AT> FLASH            /* VMA in RAM, LMA in Flash */
 
  .bss : {
    . = ALIGN(4);
    _sbss = .;
    *(.bss*)
    *(COMMON)
    . = ALIGN(4);
    _ebss = .;
  } > RAM                      /* no AT>: nothing to load, just zeroed */
}

Har choice justified: .isr_vector, .text, .rodata teen alag output sections hain requested order mein (prompt se exactly match); KEEP table ko protect karta hai (Ex 3.2); ALIGN(4) har boundary ko word-aligned rakhta hai taaki copy loop legal ho; AT> FLASH .data ko do addresses deta hai (Ex 2.2); .bss ka koi AT> nahi hai kyunki yeh boot pe zero hota hai, copy nahi hota.

(a)

• _sidata = LOADADDR(.data) = teen code sections ke baad Flash cursor = $O_{FLASH}+\text{0x3000}=\text{0x08003000}$.
• _sdata = ADDR(.data) = .data ke start pe RAM cursor. .data RAM mein pehla hai, toh yeh $O_{RAM}=\text{0x20000000}$ ke barabar hai.
• _edata: kyun _edata = _sdata + 0x40? Script mein _sdata . se *(.data*) se pehle stamp hota hai aur _edata baad mein stamp hota hai, toh _edata - _sdata exactly woh bytes hain jitne cursor ne advance kiye — woh hai SIZEOF(.data) = 0x40. Isliye: $\text{\_edata}=\text{\_sdata}+\text{SIZEOF(.data)}=\text{0x20000000}+\text{0x40}=\text{0x20000040}$

(b) Flash image $=\text{0x3000}+\text{0x40}=\text{0x3040}=12352$ bytes. Region size $=256\times 1024=262144$ bytes. Kyunki $12352\le 262144$, yeh comfortably fit hoti hai.

(a) Total RAM demand: $8\text{K}+20\text{K}+8\text{K}+16\text{K}+4\text{K}=56\text{K}$ $56\text{K}\le 64\text{K}$, toh yeh fit hota hai. (b) Bacha hua: $64-56=8\text{K}=8192\text{ bytes}$ (c) Heap double karne se $16\text{K}$ add hota hai, $56+16=72\text{K}>64\text{K}$ → 8K se overflow. Linker "region RAM overflowed" error emit karega. Sabse saste fixes jo functionality rakhte hain:

• Jo data genuinely constant hai lekin galti se RAM mein hai, use .rodata mein (Flash mein) move karo — bina kisi cost ke RAM free hoga.
• Ya, agar 32K heap genuinely required hai, koi software trick RAM nahi banati: tumhe zyada RAM wala chip lena padega. Lekin sabse sasta software-only move hai 8K slack reclaim karna + agar measurements allow karen toh over-provisioned stack/DMA buffer shrink karna. Koi free lunch nahi hai — RAM ek hard physical limit hai ($\le L_{RAM}$).

Kyun invariant hold karta hai. .data ek contiguous block occupy karta hai. RAM mein yeh _sdata … _edata span karta hai, toh uski size $\text{\_edata}-\text{\_sdata}$ hai. Flash mein wahi same bytes _sidata se start hoke mirror hote hain (Figure 1 mein left–right amber twins, Figure 2 mein mirror). Kyunki copy byte-for-byte hai, Flash mirror mein bilkul same number of bytes hone chahiye, yaani _sidata se _sidata + (\_edata - \_sdata) tak. Agar yeh dono sizes disagree karti, toh ya kuch init values kabhi copy na hote ya loop mirror ke baad padh leta. Linker equality guarantee karta hai kyunki dono same SIZEOF(.data) se compute hoti hain.

Word count. uint32_t (4-byte) pointers ke saath: $N_{words}=\frac{\text{\_edata}-\text{\_sdata}}{4}$ assuming .data 4-byte aligned hai aur size 4 ka multiple hai (Ex 4.1 mein ALIGN(4) directives guarantee karte hain). Ex 4.2 ke numbers ke liye, $\text{0x40}/4=16$ words.

Flash image mein .text + .rodata + .data count hota hai; RAM mein .data + .bss + stack + heap count hota hai. .data dono mein aata hai kyunki uske do addresses hain (LMA in Flash, VMA in RAM).