Noesis
5.5.17 · D5 · HinglishEmbedded Systems & Real-Time Software

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

1,486 words7 min read↑ Read in English

5.5.17 · D5 · Coding › Embedded Systems & Real-Time Software › Linker scripts — memory regions, sections (.text, .data, .bs

Neeche use hone wale terms, ek baar define kar diye taaki kuch bhi undefined na rahe:

  • LMA = Load Memory Address = woh jagah jahan ek section ke bytes flashed image mein physically baithe hain.
  • VMA = Virtual Memory Address = woh jagah jahan section code run hote waqt expected to be hai (uska "run address").
  • .bin / image = woh raw bytes jo actually Flash mein burn hoti hain.
  • Reset_Handler = woh pehla code jo power-up par run hota hai, main() se pehle — dekho Startup code & Reset_Handler.

True or false — justify

.text ka LMA aur VMA same hota hai.
True. Code Flash se in-place execute hota hai, isliye uska load address aur run address same Flash address hota hai — copy karne ki koi zaroorat nahi.
.data ka LMA aur VMA same hota hai.
False. Iske initial values Flash mein store hote hain (LMA) lekin variables writable hone chahiye, isliye woh RAM mein run hote hain (VMA); dono addresses alag hote hain, aur yahi reason hai ki AT> FLASH exist karta hai.
.bss Flash mein burn hone wali .bin file mein bytes contribute karta hai.
False. Sirf uski size record hoti hai; actual zeros ek startup loop dwara RAM mein likhe jaate hain, isliye image mein koi .bss bytes nahi hote.
.data .bin file mein bytes contribute karta hai.
True. Iske initial values power-off ke baad bhi survive karne chahiye, isliye woh bytes physically Flash mein rehte hain (LMA par) aur boot par RAM mein copy hote hain.
Startup se copy loop hatane par initialized globals RAM jis value par power up hua us par rahenge.
True. Flash→RAM copy ke bina, RAM mein garbage rehta hai; int x = 5; tab tak 5 nahi hoga jab tak kuch us par write na kare.
Agar tum MEMORY { } sizes delete kar do, toh linker silently ek working image produce karega.
False. Sizes hi woh tarika hai jisse linker overflow detect karta hai; bounded LENGTH ke bina woh tumhe warn nahi kar sakta jab koi region overrun ho, isliye bugs runtime par aate hain.
Larger .bss tumhari .bin file ko bada banata hai.
False. .bss sirf RAM usage aur recorded size field ko badhata hai; flashed image ka size unaffected rahta hai kyunki koi zeros store nahi hote.
Vector table ke around KEEP() optional hai agar tum kabhi garbage collection enable nahi karte.
True lekin fragile. --gc-sections off hone par woh waise bhi survive karta hai, lekin uss par rely karna ek trap hai — KEEP add karo taaki build flags chahe jo bhi ho, build correct rahe.
PC par, .data copy karna bhool jaana bhi initialized globals ko todta hai.
False. OS loader woh copy tumhare liye karta hai; yeh danger sirf bare-metal mein unique hai jahan tum loader ho.

Spot the error

.bss : { ... } > RAM AT> FLASH — kya galat hai?
AT> FLASH pointless hai: .bss mein koi initial values nahi hain jo load ki ja sakein, isliye load address ke liye koi kaam nahi hai; yeh intent waste karta hai aur readers ko confuse kar sakta hai.
.data : { ... } > FLASH (no RAM) — kya toot jaata hai?
Variables Flash se run karenge aur unwritable honge; runtime par koi bhi x = 3; ya toh fault karega ya silently fail hoga. .data RAM mein run hona chahiye (> RAM AT> FLASH).
Startup .bss ko zero karta hai lekin loop _sdata/_edata bounds use karta hai — kya bug hai?
Yeh .bss ke bajaye .data region ko zero karta hai, tumhari abhi-copy-ki-gayi initial values ko wipe karta hai aur .bss ko uninitialized chhod deta hai. _sbss/_ebss use karo.
_edata = _sdata; (size add karna bhool gaye) — kya consequence hai?
Copy loop zero iterations run karta hai kyunki start equals end hai, isliye .data kabhi copy nahi hoti; initialized globals garbage hi rehte hain.
Flash (rwx) declare hua hai aur code runtime par Flash mein ek global write karne ki koshish karta hai — real problem kya hai?
Attribute yahan cosmetic hai; real issue yeh hai ki Flash physically runtime par casually write nahi ki ja sakti, isliye write lost ho jaati hai ya fault karti hai, chahe w letter ho ya na ho.
Vector table .text mein *(.text*) ke baad place ki gayi — yeh kyun fail ho sakti hai?
CPU reset vector ko ek fixed low address se read karta hai; agar table pehle place nahi ki gayi (ya jahan CPU ko region ka address 0 expect karna ho), toh CPU boot par garbage par jump karega.

Why questions

.data ko do addresses ki zaroorat kyun hoti hai?
Non-volatility (Flash, power-off ke baad survive karta hai) aur writability (RAM) ek hi address mein coexist nahi kar sakte, isliye value ek jagah store hoti hai aur doosri jagah run hoti hai.
Flash mein zeros store karne ke bajaye .bss ko ek loop mein zero kyun karte hain?
Hazaron zeros store karna Flash waste karta hai; sirf size record karna plus ek tiny loop boot par kuch bytes aur thoda waqt leta hai.
.bss zeroing aur .data copying main() se pehle kyun honi chahiye?
Koi bhi C code jo ek global read karta hai, assume karta hai ki usme pehle se correct value hai; pehle main() run karna garbage read karayega.
Vector table ke liye specifically KEEP() kyun chahiye?
Koi bhi ise symbol name se reference nahi karta, isliye garbage collection sochta hai ki yeh dead code hai aur ise drop kar deta hai — phir CPU kuch bhi nahi par boot karta.
Linker script _sdata aur _ebss jaise symbols kyun export karta hai?
Startup C code ke paas section addresses jaanne ka koi tarika nahi hota; linker unhe compute karta hai aur unhe symbols ke roop mein hand over karta hai jo loop bounds ke roop mein use kar sake.
RAM usage .data + .bss + stack + heap se kyun measure hoti hai, lekin Flash usage .text + .rodata + .data se?
Runtime par .data aur .bss dono RAM occupy karte hain; image mein sirf .data ke initial bytes (.bss nahi) code aur constants ke saath Flash mein rehte hain.

Edge cases

Ek global int y; (kabhi assign nahi hua) — kaun sa section, aur kya yeh .bin mein hai?
Zero-initialized, isliye yeh .bss mein jaata hai aur image mein koi bytes contribute nahi karta — sirf size aur ek boot-time zeroing.
Ek global int x = 0; explicitly zero set kiya gaya — .data ya .bss?
.bss, kyunki value zero hai; compilers explicit-zero globals wahan rakhte hain Flash bachane ke liye, bilkul uninitialized ones ki tarah.
Ek const int table[] = {...} — yeh kahan rehta hai aur run karta hai?
Flash mein .rodata mein, LMA aur VMA dono ke liye; yeh read-only hai, isliye ise kabhi RAM mein copy karne ki zaroorat nahi.
.data empty hai (koi initialized globals nahi) — kya copy loop phir bhi safe hai?
Haan: _sdata == _edata, isliye loop zero iterations karta hai aur kuch harmful nahi karta.
RAM ki total requested size RAM region ki LENGTH se zyada hai — yeh kab pata chalta hai?
Link time par — linker region overflow par error deta hai, yahi wajah hai ki correct sizes declare karna utna zaroori hai jitna lagta nahi.
Stack aur heap same RAM region mein ek doosre ki taraf grow karte hain — kya silent failure hoti hai?
Stack/heap collision data corrupt karta hai bina kisi linker warning ke, kyunki dono runtime-only hain aur unka peak usage link time par pata nahi hota.