মেমরির ভিত্তি — address binding, logical আর physical address

১ · মেমরি ম্যানেজমেন্ট কেন — এক লাইব্রেরি, অনেক পাঠক

একটি পাবলিক লাইব্রেরির পড়ার ঘর ভাবুন। টেবিল সীমিত, পাঠক অনেক। লাইব্রেরিয়ানকে কয়েকটি কাজ করতে হয়: প্রত্যেককে একটি জায়গা দেওয়া; কেউ যেন পাশের জনের খাতা-বই নিয়ে না নেয়; কেউ উঠে গেলে তার জায়গা অন্য কাউকে দেওয়া; আর একটি দামি অভিধান সবাই যেন ভাগ করে ব্যবহার করতে পারে, প্রত্যেকের জন্য আলাদা কপি না কিনে। কম্পিউটারের RAM ঠিক এই পড়ার ঘর, আর লাইব্রেরিয়ান হলো OS-এর memory management অংশ।

পর্ব ৮-এ (প্রসেসের memory layout) দেখেছেন, প্রতিটি প্রসেসের নিজের text, data, BSS, heap আর stack আছে। একটি সাধারণ ল্যাপটপে একসাথে কয়েকশো প্রসেস থাকে। সবার মেমরি একই RAM চিপে। তাই চারটি প্রশ্নের উত্তর OS আর হার্ডওয়্যারকে মিলে দিতে হয়:

CPU সরাসরি কী ছুঁতে পারে

একটি মৌলিক সত্য দিয়ে শুরু করা যাক: CPU সরাসরি পড়তে-লিখতে পারে শুধু নিজের register আর main memory. Machine instruction-এর argument হিসেবে মেমরি-ঠিকানা দেওয়া যায়, কিন্তু ডিস্কের ঠিকানা দেওয়া যায় না। ডিস্ক বা SSD-র ডেটা আগে I/O করে RAM-এ আনতে হয় (পর্ব ৩৯), তারপরই CPU তা ব্যবহার করতে পারে। তাই চলমান প্রোগ্রামের কোড আর যে ডেটা নিয়ে সে কাজ করছে, দুটোই RAM-এ থাকতে হবে।

গতির পার্থক্যও বড়। Register একটি CPU cycle-এর মধ্যেই পাওয়া যায়, অথচ RAM থেকে একটি মান আনতে অনেক cycle লাগতে পারে — মাঝের এই ফাঁক ঢাকতে cache থাকে। এই memory hierarchy আর cache-এর বিস্তারিত পর্ব ৪-এ (memory hierarchy) দেখেছেন; এখানে শুধু মনে রাখুন: সুরক্ষা-যাচাইটি প্রতিটি মেমরি-ব্যবহারে হতে হবে, আর তাতে বাড়তি সময় প্রায় লাগা চলবে না. প্রতিবার kernel-কে ডেকে জিজ্ঞেস করা অসম্ভব — সেটি হাজার গুণ ধীর হবে। এ কারণেই নিচের সব কৌশলের কেন্দ্রে আছে ছোট, দ্রুত হার্ডওয়্যার।

২ · Base আর limit register — হার্ডওয়্যারের দারোয়ান

সুরক্ষার সবচেয়ে সরল ব্যবস্থা দিয়ে শুরু করি। ধরা যাক প্রতিটি প্রসেস RAM-এর একটি টানা (contiguous) অংশ পায়। CPU-তে দুটি বিশেষ register থাকে:

• Base register — প্রসেসের এলাকার সবচেয়ে ছোট বৈধ physical ঠিকানা।
• Limit register — এলাকার আকার (কত বাইট)।

বৈধ ঠিকানা তাহলে base থেকে base + limit − 1 পর্যন্ত। User mode-এ প্রসেস যতবার মেমরিতে যায় — instruction আনতে, ডেটা পড়তে বা লিখতে — হার্ডওয়্যার দুটি তুলনা করে:

             base                 base + limit
               |                       |
 CPU -- addr --+--> addr >= base ? --yes--> addr < base+limit ? --yes--> memory
                         |                           |
                         no                          no
                         v                           v
                  trap to OS: addressing error (Linux: SIGSEGV)

দুটি সূক্ষ্ম কিন্তু জরুরি কথা। প্রথম, register দুটি কে বসায়? শুধু kernel, কারণ base আর limit বসানোর নির্দেশগুলো privileged instruction — user mode-এ চালালে নিজেই trap হয় (পর্ব ৪, privilege mode). প্রসেস যদি নিজের limit বাড়াতে পারত, পুরো ব্যবস্থাই অর্থহীন হতো। Context switch-এর সময় (পর্ব ৯) dispatcher নতুন প্রসেসের PCB থেকে তার base আর limit পড়ে register-এ বসায়। দ্বিতীয়, kernel নিজে কি আটকা পড়ে? না। Kernel mode-এ এই যাচাই সাধারণত বন্ধ থাকে, যাতে OS যেকোনো প্রসেসের মেমরিতে ডেটা কপি করতে পারে (যেমন read()-এর ফল ব্যবহারকারীর buffer-এ রাখা), বা প্রসেসকে ডিস্কে সরাতে পারে।

হাতে হিসাব — কোন ঠিকানা বৈধ

পাঠ্যবইয়ের একটি প্রচলিত উদাহরণ নিই: base = 300040, limit = 120900. তাহলে base + limit = 300040 + 120900 = 420940, আর বৈধ পরিসর ৩০০০৪০ থেকে ৪২০৯৩৯ (৪২০৯৪০ নিজে বৈধ নয়, কারণ শর্ত “≥ base + limit হলে trap”). নিচের ডায়াগ্রামে তিনটি ঠিকানা যাচাই হতে দেখুন:

1kernel: base = 300040; limit = 1209002CPU (user mode) wants address A3if (A < base)          -> trap4if (A >= base + limit) -> trap5else -> go to memory6trap: kernel handles addressing error

এই ব্যবস্থার সীমাও এখনই চোখে পড়ে। প্রসেসকে RAM-এর একটি টানা অংশ দিতে হয়, আর বিভিন্ন আকারের প্রসেস আসা-যাওয়া করলে মাঝে ছোট ছোট ফাঁকা জায়গা থেকে যায় — fragmentation. এটি আর তার সমাধানের কৌশল (first fit, best fit, buddy system) পর্ব ৩১-এর বিষয়। আর একটি প্রসেসের ভেতরে কোড শুধু-পড়ার আর ডেটা পড়া-লেখার — এমন আলাদা অনুমতি base-limit দিতে পারে না; সেজন্য পরে আসবে paging (পর্ব ৩২) আর segmentation (পর্ব ৩৪)।

৩ · Address binding — ঠিকানা কখন পাকা হয়

আপনি C-তে লিখলেন count = count + 1;. এখানে count একটি নাম — CPU নাম বোঝে না, বোঝে ঠিকানা। এই নাম থেকে আসল মেমরি-ঠিকানায় পৌঁছাতে কয়েকটি ধাপ পার হয়। Compiler নামটিকে বলে “এই object file-এর data section-এর শুরু থেকে ১৬ বাইট দূরে”; linker বলে “executable-এর শুরু থেকে 0x4010-এ”; শেষে কেউ একজন বলে “RAM-এর অমুক ঘরে”। এক ধরনের ঠিকানা থেকে আরেক ধরনে এই মেলানোর কাজকে বলে address binding. মূল প্রশ্ন: শেষ মেলানো, অর্থাৎ physical ঠিকানা ঠিক করা, কখন হয়? উত্তর তিন রকম হতে পারে।

বাস্তবের উদাহরণ

Compile time — MS-DOS-এর .COM প্রোগ্রাম। পাঠ্যবইয়ের প্রিয় উদাহরণ। .COM ফাইলে কোনো header বা relocation তালিকা নেই; machine code ধরে নেয় সে নিজের segment-এর offset 0x100-এ শুরু হবে (আগের ২৫৬ বাইটে DOS একটি তথ্য-ব্লক রাখে)। পুরো প্রোগ্রাম একটি ৬৪ KB segment-এ আঁটতে হয়। একটি সূক্ষ্মতা: x86-এর real mode-এ segment register থাকায় DOS আসলে segment-টি যেকোনো জায়গায় বেছে নিতে পারত, তাই কঠোর অর্থে offset-গুলোই compile time-এ পাকা, পুরো physical ঠিকানা নয়। আরও খাঁটি উদাহরণ হলো boot sector-এর কোড (পর্ব ৭), যা সবসময় physical ঠিকানা 0x7C00-এ বসে, আর ছোট microcontroller-এর firmware, যা flash-এর নির্দিষ্ট ঠিকানায় লেখা হয়।

Load time — DOS-এর .EXE. .EXE ফাইলের (MZ ফরম্যাট) header-এ একটি relocation table থাকে — “এই এই জায়গায় segment-এর মান আছে, লোড করার সময় আসল segment যোগ করে দিতে হবে”। DOS প্রোগ্রাম লোড করার সময় সেগুলো ঠিক করে দিত। আজও একটি জায়গায় load-time ধারণা জীবিত: Linux-এর dynamic linker shared library লোড করার পর তার কিছু ঠিকানা (GOT) পূরণ করে — অংশ ৬-এ দেখবেন।

Execution time — আজকের প্রায় সব OS. Linux, Windows, macOS, Android, iOS — সবাই প্রতিটি মেমরি-ব্যবহারে MMU দিয়ে অনুবাদ করে। এর জন্যই একটি প্রসেস ডিস্কে swap হয়ে আবার RAM-এর সম্পূর্ণ অন্য জায়গায় ফিরতে পারে, আর প্রসেস কিছুই টের পায় না।

৪ · Logical বনাম physical address — আর MMU

Execution-time binding থেকে একটি গুরুত্বপূর্ণ ভাগ আসে। CPU-তে চলা প্রোগ্রাম যে ঠিকানা তৈরি করে, তাকে বলে logical address (অনেক বইয়ে virtual address; এই মডিউলে দুটি একই অর্থে)। মেমরি-হার্ডওয়্যার যে ঠিকানা পায় — RAM-এর আসল ঘরের নম্বর — তা physical address. মাঝখানে বসে অনুবাদ করে MMU (memory management unit), যা আজ CPU চিপেরই অংশ।

• একটি প্রোগ্রাম যত logical ঠিকানা তৈরি করতে পারে, তাদের সেট logical address space; সেগুলোর অনুবাদ করা physical ঠিকানার সেট physical address space.
• Compile-time আর load-time binding-এ logical আর physical ঠিকানা একই — অনুবাদের কিছু নেই।
• Execution-time binding-এ দুটি আলাদা. প্রোগ্রাম কখনো physical ঠিকানা দেখে না; একটি পয়েন্টার ছাপলে আপনি logical ঠিকানাই দেখেন।

সবচেয়ে সরল MMU হলো আগের base register-এর একটু ভিন্ন রূপ, যার নাম relocation register. নিয়ম: প্রোগ্রামের প্রতিটি logical ঠিকানার সাথে relocation register-এর মান যোগ হয়, তারপর মেমরিতে যায়। পাঠ্যবইয়ের বিখ্যাত উদাহরণ: relocation register = ১৪০০০ হলে logical ঠিকানা ৩৪৬ যায় physical 14346-এ। Limit register তখন logical ঠিকানার সাথে তুলনা হয় — আগে যাচাই, তারপর যোগ:

                 limit = 3000          relocation = 14000
                      |                        |
 CPU -- logical 346 --+--> 346 < 3000 ? --yes--> (+) --> physical 14346 --> memory
                               |
                               no
                               v
                       trap: addressing error

এখন একটি ছোট সিমুলেটরে পুরো ব্যাপারটি চালিয়ে দেখুন। দুটি প্রসেস P1 আর P2-এর relocation ও limit তাদের PCB-তে রাখা আছে। Context switch-এ kernel সেই মান MMU-তে বসায়। মাঝে kernel P1-কে RAM-এর অন্য জায়গায় সরায় — দেখুন P1-এর জন্য কী কী বদলাতে হয়:

// each process's saved registers (kept in its PCB by the kernel)
const pcb = {
  P1: { reloc: 14000, limit: 3000 },
  P2: { reloc: 20000, limit: 5000 },
};
let mmu = null;                          // what is loaded in the MMU right now
function load(p) { mmu = { name: p, ...pcb[p] }; }     // privileged: kernel only
function translate(logical) {
  if (logical >= mmu.limit)              // hardware check first ...
    return `TRAP  (${logical} >= limit ${mmu.limit}) -> kernel handles it`;
  return `physical ${logical + mmu.reloc}`;            // ... then add relocation
}
const trace = [
  ['switch', 'P1'], ['use', 0], ['use', 346], ['use', 2999], ['use', 3000],
  ['switch', 'P2'], ['use', 346], ['use', 4500],
  ['move', 'P1', 30000],                 // kernel copies P1 elsewhere (e.g. compaction)
  ['switch', 'P1'], ['use', 346],
];
for (const [op, a, b] of trace) {
  if (op === 'switch') {
    load(a);
    console.log(`-- switch to ${a}: MMU relocation=${mmu.reloc}, limit=${mmu.limit}`);
  } else if (op === 'move') {
    pcb[a].reloc = b;
    console.log(`-- kernel moves ${a} to ${b}; only the value in its PCB changes`);
  } else {
    console.log(`${mmu.name} logical ${String(a).padStart(4)} -> ${translate(a)}`);
  }
}

-- switch to P1: MMU relocation=14000, limit=3000
P1 logical    0 -> physical 14000
P1 logical  346 -> physical 14346
P1 logical 2999 -> physical 16999
P1 logical 3000 -> TRAP  (3000 >= limit 3000) -> kernel handles it
-- switch to P2: MMU relocation=20000, limit=5000
P2 logical  346 -> physical 20346
P2 logical 4500 -> physical 24500
-- kernel moves P1 to 30000; only the value in its PCB changes
-- switch to P1: MMU relocation=30000, limit=3000
P1 logical  346 -> physical 30346

পরীক্ষার হিসাব — logical address space-এর আকার

আরেক ধরনের সহজ কিন্তু প্রচলিত প্রশ্ন: “logical ঠিকানা ১৬ bit হলে logical address space কত বড়?” উত্তর ২^১৬ = ৬৫৫৩৬ ঠিকানা; প্রতিটি ঠিকানায় এক বাইট ধরলে ৬৪ KiB. ৩২ bit হলে ২^৩২ বাইট = ৪ GiB. লক্ষ করুন, এই আকার RAM কতটুকু আছে তার ওপর নির্ভর করে না — logical আর physical address space আলাদা জিনিস, একটি অন্যটির চেয়ে বড় বা ছোট হতে পারে (ভাবনার প্রশ্ন ৫)। আর logical জগৎকে টুকরো করে RAM-এর যেকোনো জায়গায় ছড়িয়ে রাখার কৌশল হলো paging — পর্ব ৩২.

৫ · Compile → link → load — object file, symbol আর relocation

এতক্ষণ ধরে নিয়েছি প্রোগ্রাম একটি টুকরো। বাস্তবে একটি প্রোগ্রাম অনেক ফাইল থেকে আসে — আপনার কয়েকটি .c ফাইল, আর C library-র হাজারো ফাংশন। প্রতিটি .c ফাইল (তার #include করা সবকিছুসহ) আলাদা করে compile হয়; এই এককের নাম translation unit. Preprocessor, compiler আর assembler-এর ভেতরের কাজ C কোর্সের toolchain পর্বে দেখানো আছে; এখানে আমরা দেখব OS-এর দিক — ঠিকানা কোথায় ফাঁকা থাকে, আর কে কখন তা পূরণ করে।

1. Compile (gcc -c) — প্রতিটি translation unit থেকে একটি object file (.o, Windows-এ .obj). এতে machine code আছে, কিন্তু অন্য ফাইলের ফাংশন বা ভ্যারিয়েবলের ঠিকানার জায়গায় শূন্য বসানো। সাথে দুটি তালিকা: symbol table (এই ফাইলে কোন নাম সংজ্ঞায়িত, কোনটি বাইরে থেকে লাগবে) আর relocation entry (কোন বাইটে কোন নামের ঠিকানা বসাতে হবে)।
2. Link (ld, সাধারণত gcc-ই ডাকে) — linker সব object file আর library একসাথে নেয়। প্রথমে symbol resolution: প্রতিটি undefined নামের জন্য ঠিক একটি সংজ্ঞা খোঁজা। তারপর section সাজিয়ে প্রত্যেকের ঠিকানা ঠিক করা, আর relocation: ফাঁকা জায়গায় সেই ঠিকানা বসানো। ফল একটি executable, Linux-এ ELF ফরম্যাটে।
3. Load (execve) — চালানোর সময় loader ফাইলটি পড়ে প্রসেসের address space-এ বসায়, দরকারি shared library আনে আর main-এর আগে শুরুর কোডে লাফ দেয়।

নিচের bash স্ক্রিপ্ট দুটি translation unit বানায়: util.c একটি ভ্যারিয়েবল আর একটি ফাংশন সংজ্ঞায়িত করে, main.c শুধু সেগুলো ব্যবহার করে। তারপর nm দিয়ে symbol, readelf দিয়ে relocation entry দেখায়, link করে চালায়, আর link-এর পরের symbol দেখায়:

# two translation units: util.c defines, main.c only uses
cat > util.c <<'EOF'
int counter = 5;                       /* defined here (data) */
int square(int x) { return x * x; }    /* defined here (text) */
EOF
cat > main.c <<'EOF'
#include <stdio.h>
extern int counter;                    /* lives in another file */
int square(int x);
int main(void) { printf("%d\n", square(counter)); return 0; }
EOF
gcc -c util.c main.c                   # compile only -> util.o, main.o
echo "== nm util.o ==";  nm util.o
echo "== nm main.o (U = undefined, needs someone else) =="; nm main.o
echo "== relocation entries in main.o (offset, type, symbol) =="
readelf -rW main.o | sed -n '/rela.text/,/^$/p' | awk 'NR>2 && NF {print $1, $3, $5}'
echo "== link and run =="
gcc -o app main.o util.o && ./app
echo "== nm app: now with addresses =="
nm app | grep -E ' (square|counter|main)$|printf'

== nm util.o ==
0000000000000000 D counter
0000000000000000 T square
== nm main.o (U = undefined, needs someone else) ==
                 U counter
0000000000000000 T main
                 U printf
                 U square
== relocation entries in main.o (offset, type, symbol) ==
000000000000000a R_X86_64_PC32 counter
0000000000000011 R_X86_64_PLT32 square
000000000000001a R_X86_64_PC32 .rodata
0000000000000027 R_X86_64_PLT32 printf
== link and run ==
25
== nm app: now with addresses ==
0000000000004010 D counter
0000000000001149 T main
                 U printf@GLIBC_2.2.5
000000000000117b T square

Symbol resolution-এর দুটি ব্যর্থতা প্রতিটি C প্রোগ্রামারের চেনা। কোনো নামের সংজ্ঞা একেবারেই না পেলে: undefined reference to `square' (যেমন util.o link করতে ভুলে গেলে)। দুটি ফাইলে একই global সংজ্ঞা থাকলে: multiple definition of `counter'. দুটোই linker-এর error, compiler-এর নয় — তাই প্রতিটি ফাইল আলাদা করে ঠিকঠাক compile হলেও শেষে আটকে যেতে পারে।

Static linking বনাম dynamic linking

উপরে printf কেন executable-এ ঢুকল না? কারণ ডিফল্টভাবে gcc dynamic linking করে। দুটি পথ পাশাপাশি দেখুন:

এবার একটি printf কল source থেকে CPU পর্যন্ত কোন পথে যায়, ধাপে ধাপে দেখুন। প্রতিটি ধাপে ফাইলের ভেতরের ঠিকানাটি কীভাবে বদলায় খেয়াল করুন:

#include <stdio.h>
int main(void) {
    printf("%d\n", 42);
    return 0;
}

main:  ...
       e8 00 00 00 00      call ????
relocation: offset of those 4 bytes, R_X86_64_PLT32, printf - 4
nm: U printf

main:        call printf@plt
printf@plt:  jmp  *GOT[printf]     ; GOT slot still to be filled
dynamic section: NEEDED libc.so.6
interpreter:     /lib64/ld-linux-x86-64.so.2

map hi            at a random base      (PIE + ASLR)
map ld-linux.so.2 at another random base
new stack: argv, envp, auxv
jump to ld.so, not to main

read NEEDED -> find libc.so.6 -> mmap it (random base)
look up "printf" in libc's symbol table
GOT[printf] = 0x7f...  (address inside libc)   ; BIND_NOW
jump to the program's entry -> main

main -> printf@plt -> jmp *GOT[printf] -> printf in libc
printf -> write(1, "42\n", 3) -> system call
$ ./hi
42

৬ · Dynamic linking-এর ভেতরে — PLT, GOT, lazy binding আর dlopen

প্রশ্ন জাগে: library-র কোডের ঠিকানা প্রতিবার আলাদা হলে কলের ঠিকানা কোডে সরাসরি লিখে দিলেই তো হয়? সমস্যা হলো, তাতে কোড পাতাগুলো প্রতিটি প্রসেসে আলাদা করে বদলাতে হতো — তখন সেগুলো আর ভাগ করা যেত না, আর লেখা যায় এমন কোড নিরাপত্তার জন্যও খারাপ। সমাধান হলো এক স্তর পরোক্ষতা (indirection): কোড কখনো বদলায় না; বদলায় শুধু ডেটার একটি টেবিল.

• GOT (global offset table) — প্রতিটি প্রসেসের ডেটা অংশে একটি টেবিল, যার প্রতিটি ঘরে একটি বাইরের ফাংশন বা ভ্যারিয়েবলের আসল ঠিকানা লেখা হয়। প্রতি প্রসেসে আলাদা কপি।
• PLT (procedure linkage table) — কোড অংশে ছোট ছোট stub, প্রতিটি বাইরের ফাংশনের জন্য একটি। Stub-এর কাজ: “GOT-এর আমার ঘরে যে ঠিকানা আছে, সেখানে লাফ দেওয়া”। কোড শুধু-পড়ার আর সব প্রসেসে ভাগ করা।

এখন ঠিকানা কখন খোঁজা হবে? দুটি নীতি। Lazy binding: শুরুতে GOT-এর ঘরে একটি “আগে আসল ঠিকানা খুঁজে আনতে হবে” ধরনের ঠিকানা থাকে, আর প্রথম কলে dynamic linker আসল ঠিকানা খুঁজে লিখে দেয়। যে ফাংশন কখনো ডাকা হয় না, তার খোঁজার খরচও লাগে না — বড় প্রোগ্রামের শুরু দ্রুত হয়। BIND_NOW: শুরুতেই সব খোঁজা, তারপর RELRO-র মাধ্যমে GOT শুধু-পড়ার করে দেওয়া — একটু ধীর শুরু, কিন্তু বাগ দিয়ে GOT বদলে কলকে অন্য দিকে ঘোরানো যায় না। নিচে lazy পথটি সরলীকৃতভাবে দেখুন (ঠিকানাগুলো সরলীকৃত উদাহরণ):

1main:        call printf@plt2printf@plt:  jmp  *GOT[printf]      ; slot at 0x3fd03             push 0 ; jmp PLT0       ; lazy stub4PLT0:        push GOT[1] ; jmp *GOT[2]5ld.so:       _dl_runtime_resolve -> find "printf"6             GOT[printf] = libc printf; jump there7libc:        printf(...) ... ret8main (later): call printf@plt

এবার নিজের চোখে দেখুন। নিচের স্ক্রিপ্ট একই প্রোগ্রাম তিনভাবে বানায় — ডিফল্ট dynamic, lazy binding চেয়ে dynamic, আর static — তারপর আকার, dependency, ফাইলের ধরন, তিনটি আলাদা প্রসেসে libc-এর শুরুর ঠিকানা, আর glibc-এর LD_DEBUG দিয়ে printf কখন bind হয় তা দেখায়। (ldd কমান্ডটি শুধু নিজের বা বিশ্বস্ত ফাইলে চালাবেন; অচেনা ফাইলের জন্য readelf -d নিরাপদ।)

# one tiny program, linked three ways
cat > hi.c <<'EOF'
#include <stdio.h>
#include <unistd.h>
int main(void) { write(2, "main starts\n", 12); printf("%d\n", 42); return 0; }
EOF
gcc -o hi_dyn hi.c                     # default: dynamic linking
gcc -Wl,-z,lazy -o hi_lazy hi.c        # dynamic, ask for lazy binding
gcc -static -o hi_sta hi.c 2>/dev/null || echo "(static libc not installed here)"
echo "== file sizes (bytes) =="
ls -l hi_dyn hi_sta 2>/dev/null | awk '{print $5, $9}'
echo "== what hi_dyn needs at load time =="
readelf -d hi_dyn | grep -E 'NEEDED|FLAGS' | awk '{$1=""; print}'
ldd ./hi_dyn | awk '{print $1}'
echo "== hi_sta needs =="; ldd ./hi_sta 2>&1 | tr -d '\t'
echo "== type of hi_dyn =="; readelf -h hi_dyn | grep 'Type:' | sed 's/^ *//'
echo "== libc start address in three separate processes =="
cat /proc/sys/kernel/randomize_va_space
for i in 1 2 3; do grep -m1 'libc.so' /proc/self/maps | cut -d- -f1; done
for p in hi_dyn hi_lazy; do
  echo "== $p: when is printf bound? =="
  LD_DEBUG=bindings ./$p 2>&1 >/dev/null | grep -oE "main starts|symbol .printf'"
done

== file sizes (bytes) ==
16000 hi_dyn
785304 hi_sta
== what hi_dyn needs at load time ==
 (NEEDED) Shared library: [libc.so.6]
 (FLAGS) BIND_NOW
 (FLAGS_1) Flags: NOW PIE
linux-vdso.so.1
libc.so.6
/lib64/ld-linux-x86-64.so.2
== hi_sta needs ==
not a dynamic executable
== type of hi_dyn ==
Type:                              DYN (Position-Independent Executable file)
== libc start address in three separate processes ==
2
73f782cdd000
76b2d7b06000
734a72cb8000
== hi_dyn: when is printf bound? ==
symbol `printf'
main starts
== hi_lazy: when is printf bound? ==
main starts
symbol `printf'

Dynamic loading — দরকার হলে তবেই আনা

Dynamic linking-এ কোন library লাগবে তা ফাইলে আগে থেকে লেখা থাকে। Dynamic loading আরও এক ধাপ নমনীয়: প্রোগ্রাম চলার মাঝে নিজেই ঠিক করে কোন library আনবে। POSIX-এ dlopen library লোড করে একটি handle দেয়, dlsym তার ভেতরের নাম থেকে ঠিকানা দেয়; Windows-এ একই কাজ LoadLibrary আর GetProcAddress. Plugin ব্যবস্থা এভাবেই চলে. পাঠ্যবইয়ের ভাষায় dynamic loading-এর সুবিধা: যে রুটিন কখনো লাগে না (যেমন বিরল ত্রুটি সামলানোর কোড), সেটি কখনো মেমরিতে আসে না, আর এর জন্য OS-এর বিশেষ সমর্থন লাগে না — প্রোগ্রামের নকশাই যথেষ্ট।

নিচের C প্রোগ্রাম /proc/self/maps পড়ে (পর্ব ১১) দেখায় কোন ঠিকানা কোন mapping-এ পড়ে, আর libm.so.6 (math library) dlopen-এর আগে আর পরে মেমরিতে আছে কি না:

#include <stdio.h>
#include <string.h>
#include <stdint.h>
#include <dlfcn.h>
int global = 1;
/* scan /proc/self/maps: count lines naming lib; name the mapping that holds p */
static int scan(const char *lib, const void *p, char *who, size_t n) {
    FILE *f = fopen("/proc/self/maps", "r"); char line[512], perm[8], path[256];
    unsigned long lo, hi, a = (unsigned long)(uintptr_t)p; int hits = 0;
    while (f && fgets(line, sizeof line, f)) {
        path[0] = '\0';
        if (sscanf(line, "%lx-%lx %7s %*s %*s %*s %255s", &lo, &hi, perm, path) < 3) continue;
        if (lib && strstr(path, lib)) hits++;
        if (p && a >= lo && a < hi) snprintf(who, n, "%s [%s]",
            strrchr(path, '/') ? strrchr(path, '/') + 1 : path, perm);
    }
    if (f) fclose(f);
    return hits;
}
int main(void) {
    char w[300] = "?";
    printf("libm mappings before dlopen: %d\n", scan("libm.so", NULL, w, sizeof w));
    void *h = dlopen("libm.so.6", RTLD_NOW);          /* dynamic loading */
    if (!h) { printf("dlopen failed: %s\n", dlerror()); return 1; }
    double (*cosp)(double);
    *(void **)&cosp = dlsym(h, "cos");                 /* POSIX-style cast */
    printf("libm mappings after dlopen:  %d\n", scan("libm.so", NULL, w, sizeof w));
    scan(NULL, (void *)main, w, sizeof w);    printf("main   -> %s\n", w);
    scan(NULL, &global, w, sizeof w);         printf("global -> %s\n", w);
    scan(NULL, stdout, w, sizeof w);          printf("stdout -> %s\n", w);
    scan(NULL, *(void **)&cosp, w, sizeof w); printf("cos    -> %s\n", w);
    printf("cos(0) = %.1f, main below 4 GiB: %s\n", cosp(0.0),
           (uintptr_t)main < 0x100000000u ? "yes" : "no");
    return dlclose(h);
}

libm mappings before dlopen: 0
libm mappings after dlopen:  5
main   -> prog.exe [r-xp]
global -> prog.exe [rw-p]
stdout -> libc.so.6 [rw-p]
cos    -> libm.so.6 [r-xp]
cos(0) = 1.0, main below 4 GiB: yes

$ readelf -d /usr/bin/ls | grep NEEDED       # what it needs
 0x0000000000000001 (NEEDED)  Shared library: [libselinux.so.1]
 0x0000000000000001 (NEEDED)  Shared library: [libc.so.6]
$ ldconfig -p | grep 'libm.so.6'               # where the loader looks
	libm.so.6 (libc6,x86-64) => /lib/x86_64-linux-gnu/libm.so.6

PS> dumpbin /dependents C:\Windows\System32\notepad.exe
  Image has the following dependencies:
    KERNEL32.dll
    GDI32.dll
    USER32.dll
    ...

$ otool -L /bin/ls
/bin/ls:
	/usr/lib/libutil.dylib (compatibility version 1.0.0, ...)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, ...)

তিন OS-এর ধারণা এক, খুঁটিনাটি আলাদা। Windows-এ PLT/GOT-এর জায়গায় আছে import address table (IAT) — loader সাধারণত প্রোগ্রাম চালু হওয়ার সময়ই DLL-এর ফাংশনের ঠিকানা এতে লিখে দেয়, আর “delay-load” নামে lazy-র মতো একটি ঐচ্ছিক ব্যবস্থাও আছে। macOS-এ dynamic linker-এর নাম dyld, ফরম্যাট Mach-O. উপরের আউটপুটগুলো উদাহরণ — সংস্করণভেদে তালিকা বদলায়।

৭ · Position-independent code — আর ASLR কেন এর ওপর নির্ভর করে

একটি shared library দুইশো প্রসেসে ভাগ হচ্ছে, আর ASLR-এর কারণে প্রতিটি প্রসেসে সেটি বসছে আলাদা logical ঠিকানায়। তবু RAM-এ তার কোডের একটিই কপি। এটি কীভাবে সম্ভব? কোডের ভেতরে যদি কোথাও লেখা থাকত “ঠিকানা 0x7f3a1c060100-এ লাফ দিতে হবে”, তাহলে প্রতিটি প্রসেসের জন্য সেটি আলাদা হতে হতো, আর কোড ভাগ করা যেত না। সমাধান position-independent code (PIC): এমন machine code, যাতে কোনো পরম (absolute) ঠিকানা লেখা থাকে না।

• নিজের ভেতরের জিনিস — নিজের ফাংশন বা ডেটা — খোঁজা হয় PC-আপেক্ষিক হিসাবে: “এই নির্দেশ থেকে ৩০০০ বাইট দূরে”। পুরো library যেখানেই বসুক, ভেতরের দূরত্ব একই। x86-64-এ এজন্য RIP-relative addressing আছে, যা উপরের relocation তালিকার R_X86_64_PC32-এ দেখেছেন। (32-bit x86-এ এমন সরাসরি ব্যবস্থা ছিল না, তাই PIC সেখানে কিছুটা ধীর ছিল।)
• বাইরের জিনিস — অন্য library-র ফাংশন বা ভ্যারিয়েবল — খোঁজা হয় GOT থেকে, যার নিজের অবস্থানও PC-আপেক্ষিক। GOT প্রতি প্রসেসে আলাদা, কোড সবার এক।

Shared library তৈরি হয় gcc -fPIC -shared দিয়ে। আর যে executable নিজেও PIC দিয়ে তৈরি, তার নাম PIE (position-independent executable) — -fPIE -pie, আজকের Ubuntu, Fedora, Debian-এর gcc-তে ডিফল্ট। উপরের bash আউটপুটে Type: DYN (Position-Independent Executable file) ঠিক সেটিই বলছিল।

ASLR-এর সাথে সম্পর্ক

পর্ব ৮-এ (ASLR অংশ) দেখেছেন, ASLR প্রতিবার stack, heap, mmap এলাকা আর library-র শুরুর ঠিকানা এলোমেলো করে, যাতে কোনো মেমরি-বাগ কাজে লাগাতে আক্রমণকারী দরকারি কোডের ঠিকানা আগে থেকে না জানে। কিন্তু কোড যদি একটি নির্দিষ্ট ঠিকানা ধরে লেখা হয় (non-PIE), তাকে সরাতে হলে দুটি পথ: হয় load time-এ কোডের সব ঠিকানা ঠিক করা (“text relocation” — কোড পাতা লেখা যায় এমন করতে হয়, ভাগ করা যায় না, ধীরও), নয়তো না সরানো। বাস্তবে non-PIE executable না সরিয়েই চলে — ঠিক যেমন উপরের C runner-এ main প্রতিবার একই নিচু ঠিকানায় ছিল। তাই ASLR-এর পূর্ণ সুরক্ষা পেতে প্রোগ্রামকে PIE হতে হয়; নইলে প্রোগ্রামের নিজের কোড আর ডেটা অনুমেয় জায়গায় থেকে যায়।

৮ · Swapping — পুরো প্রসেস ডিস্কে, আর overlay-র ইতিহাস

সবশেষে সেই প্রশ্ন: সব প্রসেস RAM-এ না আঁটলে? ক্লাসিক উত্তর standard swapping (standard swapping): কোনো একটি প্রসেস — সাধারণত যে অনেকক্ষণ অপেক্ষায় বা কম গুরুত্বপূর্ণ — তার পুরো মেমরি-চিত্র একটি দ্রুত ডিস্কে লিখে দেওয়া (swap out), আর জায়গা খালি হলে আবার পুরোটা ফিরিয়ে আনা (swap in). যে ডিস্ক-এলাকায় এই চিত্র রাখা হয়, তার নাম backing store. পর্ব ৮-এর suspended অবস্থা আর medium-term scheduler ঠিক এই কাজের নাম।

Execution-time binding থাকলে প্রসেস ফিরে এসে RAM-এর যেকোনো খালি জায়গায় বসতে পারে — শুধু PCB-র relocation মান বদলালেই হয়, যা সিমুলেটরে দেখেছেন। Compile-time বা load-time binding-এ তাকে ঠিক আগের জায়গাতেই ফিরতে হতো।

পরীক্ষার হিসাব — swap-এর খরচ

Swap-এর প্রধান খরচ হলো ডেটা সরানোর সময় (transfer time), আর সেটি প্রসেসের আকারের সমানুপাতিক:

প্রশ্নে transfer rate যা দেওয়া থাকবে, সেটিই ব্যবহার করবেন — ৫০ MB/s পুরোনো hard disk-এর মতো একটি পাঠ্যবই-সংখ্যা; আসল গতি ডিস্ক, interface আর ফাইলের অবস্থাভেদে অনেক বদলায়। তিনটি সাধারণ ফাঁদ: (১) out আর in দুবার গোনা ভুলে যাওয়া; (২) MB (মেগাবাইট) আর Mb (মেগাবিট) গুলিয়ে ফেলা — ৮ গুণ পার্থক্য; (৩) একক মেলানো — সেকেন্ড থেকে ms করতে ১০০০ দিয়ে গুণ। আরেকটি বাস্তব কথা: শুধু যতটুকু মেমরি আসলে ব্যবহার হচ্ছে, ততটুকুই swap করা দরকার — তাই প্রসেস কতটুকু মেমরি ব্যবহার করছে তা OS-কে জানাতে হয়।

আজকের বাস্তবতা — পুরো প্রসেস নয়, page

পুরো প্রসেস সরানো এত ধীর যে আধুনিক Linux, Windows বা macOS সাধারণ অবস্থায় এটি করে না। তারা swap করে page ধরে — মেমরির ছোট টুকরো (সাধারণত ৪ KiB), শুধু যেগুলো কম ব্যবহৃত (পর্ব ৩৫–৩৭)। Linux-এর swap partition বা swap file, Windows-এর pagefile.sys — দুটোই এই page-ভিত্তিক swap.

মোবাইলে ক্লাসিক অর্থে swap প্রায় নেই। iOS অ্যাপের মেমরি flash-এ swap করে না (নতুন কিছু iPad-এ iPadOS 16 থেকে সীমিত swap এসেছে); RAM কমলে প্রথমে কম ব্যবহৃত পাতা চেপে ছোট করে (memory compression), অ্যাপকে মেমরি ছাড়তে সতর্ক করে, আর শেষে পেছনের অ্যাপ বন্ধ করে দেয় (Jetsam). Android সাধারণত flash-এ swap না করে RAM-এর ভেতরেই compress করা swap (zram) ব্যবহার করে, আর চাপ বাড়লে low-memory killer (lmkd) পেছনের অ্যাপ বন্ধ করে। কারণগুলো: flash-এর লেখার আয়ু সীমিত, ব্যাটারি খরচ, আর মোবাইলে ছোট storage. সেজন্যই মোবাইল অ্যাপকে পেছনে যাওয়ার সময় নিজের অবস্থা সংরক্ষণ করতে হয় — OS যেকোনো সময় তাকে বন্ধ করে পরে নতুন করে চালু করতে পারে। খুঁটিনাটি সংস্করণ আর নির্মাতাভেদে বদলায় (পর্ব ৫৪)।

Overlay — ইতিহাসের পাতা

Virtual memory আসার আগে, RAM-এর চেয়ে বড় প্রোগ্রাম চালানোর একটি কৌশল ছিল overlay. প্রোগ্রামার নিজে প্রোগ্রামকে টুকরো করতেন: একটি অংশ সবসময় মেমরিতে (মূল নিয়ন্ত্রক আর সাধারণ ডেটা), আর বাকি টুকরোগুলো পালা করে একই মেমরি-এলাকায় আসত। পাঠ্যবইয়ের উদাহরণ একটি দুই-pass assembler: pass 1-এর কোড ৭০ KB, pass 2-এর ৮০ KB, symbol table ২০ KB, সাধারণ রুটিন ৩০ KB — একসাথে ২০০ KB, অথচ মেমরি ধরুন ১৫০ KB. Pass 1 আর pass 2 কখনো একসাথে লাগে না, তাই overlay A = symbol table + সাধারণ রুটিন + pass 1 = ১২০ KB, overlay B = symbol table + সাধারণ রুটিন + pass 2 = ১৩০ KB; সাথে ছোট একটি overlay driver (ধরুন ১০ KB) মিলে সর্বোচ্চ ১৪০ KB — আঁটে। DOS যুগের কিছু compiler (যেমন Borland-এর টুল) overlay-র সুবিধা দিত। দাম ছিল বড়: পুরো প্রোগ্রামের গঠন প্রোগ্রামারকে মাথায় রাখতে হতো, আর ভুল হলে খুঁজে পাওয়া কঠিন। পরে OS-এর virtual memory (পর্ব ৩৫) এই কাজ স্বয়ংক্রিয় করে দেয়, তাই আজ overlay প্রায় শুধু ছোট embedded সিস্টেমে দেখা যায়।

৯ · AI-এর যুগে — linking, ঠিকানা আর মেমরির প্রশ্নে AI-কে কীভাবে ব্যবহার করবেন

“undefined reference” error, “error while loading shared libraries”, বা পরীক্ষার “logical address 346, relocation 14000” — এসব প্রশ্নে AI চটপট উত্তর দেয়। কিন্তু এই বিষয়ে AI-এর ভুলগুলো খুব চেনা ধরনের, আর এই পর্বের ধারণা থাকলে আপনি সেগুলো ধরতে পারবেন:

AI-এর উত্তর মানার আগে — চেকলিস্ট

• AI-কে OS, distro, compiler আর architecture জানিয়েছি; উত্তরের কমান্ড সেই OS-এরই কি না দেখেছি
• Library-সংক্রান্ত দাবি readelf -d, nm আর man ld.so দিয়ে নিজে মিলিয়েছি
• Base-limit, relocation বা swap-এর প্রতিটি numerical হাতে আবার করেছি — সীমার “এক বেশি” আর একক বিশেষভাবে দেখেছি
• ASLR, PIE, RELRO বা অন্য সুরক্ষা বন্ধ করার পরামর্শ মানিনি; sudo আর chmod 777 ছাড়া পথ খুঁজেছি
• ঠিকানা নিয়ে কোনো দাবি (“এই ভ্যারিয়েবল সবসময় এই ঠিকানায়”) একাধিকবার চালিয়ে পরীক্ষা করেছি
• Kernel বা glibc-এর আচরণ নিয়ে দাবির ক্ষেত্রে সংস্করণ মিলিয়েছি — পুরোনো তথ্য (যেমন dlopen-এ সবসময় -ldl লাগে) নতুন সিস্টেমে বদলে যেতে পারে