অ্যাসেম্বলার, লিংকার, লোডার — সোর্স কোড থেকে চলমান প্রোগ্রাম পর্যন্ত

পুরো toolchain একসাথে — gcc আসলে একটা orchestrator

gcc file.c -o prog লিখলে, ভেতরে প্রায় এই ক্রমেই ঘটনা ঘটে (সরলীকৃত, কিন্তু বাস্তবতার কাছাকাছি):

gcc file.c -o prog
  │
  ├─▶ preprocessor (cpp)     file.c        → file.i    (#include, #define সম্প্রসারণ)
  ├─▶ compiler proper (cc1)  file.i        → file.s    (উচ্চ-স্তরের কোড → assembly mnemonic)
  ├─▶ assembler (as)         file.s        → file.o    (mnemonic → machine code বিট)
  └─▶ linker (ld)            file.o + libs → prog      (symbol resolve, একত্র করা)

প্রতিটা ধাপ - দিয়ে শুরু হওয়া একটা flag দিয়ে থামিয়ে দেওয়া যায় — এটা নিজেই একটা দরকারি ডিবাগিং কৌশল, “ঠিক কোন ধাপে সমস্যা” তা আলাদা করতে:

Symbol table বাস্তবে কেমন দেখতে — nm

nm কমান্ড একটা object file বা executable-এর symbol table পড়ে দেখায়। প্রতিটা symbol-এর পাশে একটা অক্ষর তার ধরন বলে — T মানে defined function (.text-এ), U মানে undefined (এই ফাইলে সংজ্ঞায়িত না, অন্য কোথাও থেকে আসবে বলে আশা করা হচ্ছে)।

nm square.o

0000000000000000 T square

square এখানে T (defined, .text-এ) — কারণ এই ফাইলেই তার সংজ্ঞা আছে। এখন একটা ফাইল দেখি যেটা square আর printf দুটোই ব্যবহার করে কিন্তু নিজে সংজ্ঞায়িত করে না:

nm main.o

0000000000000000 T main
                 U printf
                 U square

main নিজেই defined (এই ফাইলে সংজ্ঞায়িত), কিন্তু printf আর square দুটোই U — undefined। এই মুহূর্তে main.o-এর ভেতরে যেখানে call square instruction আছে, সেখানে target address আসলে একটা placeholder, একটা প্রকৃত সংখ্যা না।

Relocation entries — objdump -r

objdump -r দেখায় ঠিক কোন কোন জায়গায় “পরে ঠিক করো” চিহ্ন বসানো আছে:

objdump -r main.o

RELOCATION RECORDS FOR [.text]:
OFFSET           TYPE              VALUE
0000000000000015 R_X86_64_PLT32    square-0x4
0000000000000025 R_X86_64_PLT32    printf-0x4

দুইটা লাইন — দুইটা জায়গায় (byte offset 0x15 আর 0x25) linker-কে বলা আছে “এখানে square-এর, আর এখানে printf-এর প্রকৃত ঠিকানা বসাও।” এটাই সেই “অসম্পূর্ণতা”-র বাস্তব, দেখার-যোগ্য প্রমাণ — object file সত্যিই একটা অসম্পূর্ণ পাজল-এর টুকরো, শুধু একটা তাত্ত্বিক বর্ণনা না।

Link হওয়ার পর — কী বদলায়

gcc main.o square.o -o prog
nm prog | grep -E "main|square|printf"

0000000000001139 T main
0000000000001129 T square
                 U printf

লক্ষ করুন — square এখন T (defined) হয়ে গেছে prog-এর symbol table-এ, কারণ square.o linking-এ যোগ হয়েছিল, তার সংজ্ঞা পাওয়া গেছে, ঠিকানা চূড়ান্ত হয়েছে। কিন্তু printf তখনও U — কেন? কারণ printf dynamically link হয়েছে (libc.so-তে থাকে, static ভাবে embedded হয়নি) — তার প্রকৃত ঠিকানা এখনও ঠিক হয়নি, সেটা ঠিক হবে loader/dynamic-linker চলার সময়। ldd prog দিয়ে dynamic dependency দেখা যায়:

ldd prog

linux-vdso.so.1 => (0x00007fff...)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f...)
/lib64/ld-linux-x86-64.so.2 (0x00007f...)

libc.so.6 — সেই dynamic dependency, যেটা loader runtime-এ resolve করবে। এই মুহূর্তে আমরা directly module 4-এর ভূমিতে পা রেখেছি — dynamic linker (ld-linux-x86-64.so.2) নিজেই আরেকটা প্রোগ্রাম, যেটা loader দ্বারা প্রথমেই চালু করা হয়, তারপর সে বাকি resolve করে।

Symbol binding — nm-এর অক্ষরগুলো ঠিক কী বলে

nm output-এ T/U ছাড়াও আরও কয়েকটা অক্ষর দেখা যায় — প্রতিটাই symbol-এর একটা নির্দিষ্ট binding ও section নির্দেশ করে:

Section header table — readelf -S দিয়ে সম্পূর্ণ কাঠামো দেখা

objdump/nm প্রতিটা আলাদা তথ্য আলাদাভাবে দেখায়; readelf -S পুরো ELF ফাইলের section header table-টাই একবারে দেখিয়ে দেয় — কোন section কোথায়, কত বড়, কোন ফ্ল্যাগ নিয়ে:

readelf -S square.o

Section Headers:
  [Nr] Name              Type             Address           Size
  [ 0]                   NULL             0000000000000000  00000000
  [ 1] .text             PROGBITS         0000000000000000  00000010
  [ 2] .data             PROGBITS         0000000000000000  00000000
  [ 3] .bss              NOBITS           0000000000000000  00000000
  [ 4] .symtab           SYMTAB           0000000000000000  00000048
  [ 5] .strtab           STRTAB           0000000000000000  0000000a
  [ 6] .rela.text        RELA             0000000000000000  00000018

.text-এর Size কলামে 0x10 (১৬ byte) — ঠিক আগে objdump -d-এ দেখা square function-এর ১৬ byte-এর machine code-এর সাথে মেলে। .bss-এর Type NOBITS — মানে ডিস্কে কোনো actual বাইট সংরক্ষিত না এই section-এর জন্য, শুধু “এত জায়গা লাগবে, সব শূন্যে শুরু করো” এই তথ্যটুকু রেকর্ড করা — এই লেসনের আগের টেবিলেই যা বলা হয়েছিল, এখানে সরাসরি readelf-এর আউটপুটে প্রমাণিত।

PLT/GOT — lazy binding-এর প্রকৃত mechanism

উপরে প্রতিশ্রুতি দেওয়া হয়েছিল “runtime-এ প্রথমবার call হওয়ার মুহূর্তে resolve” ব্যাপারটা ঠিক কীভাবে কাজ করে তা দেখানোর। প্রক্রিয়াটা দুটো ছোট টেবিলের সমন্বয়ে হয় — PLT (Procedure Linkage Table, কোড) আর GOT (Global Offset Table, ডেটা — ঠিকানার একটা array)।

prog-এ printf কল করলে, machine code সরাসরি printf-এর আসল ঠিকানায় jump করে না — সে jump করে একটা ছোট, স্থানীয় PLT stub-এ:

\<printf@plt>:
    jmp    *GOT[printf]        ; GOT-এ যা লেখা আছে, সেখানে jump করো

প্রথমবার printf call হলে — GOT[printf]-এ তখনও প্রকৃত ঠিকানা নেই, বরং সেটা আবার PLT-এরই আরেকটা অংশে ফিরিয়ে দেয়, যেটা dynamic linker-কে (ld.so) ডেকে বলে “এখনই printf-এর প্রকৃত ঠিকানা খুঁজে বের করো।” Dynamic linker libc.so.6-এ printf খুঁজে পায়, তার ঠিকানা GOT[printf]-এ লিখে ফেলে (patch করে), তারপর সেই ঠিকানাতেই jump করে।

দ্বিতীয়বার থেকে — GOT[printf]-এ এখন প্রকৃত ঠিকানা বসানো আছে, তাই PLT stub সরাসরি এক-ধাপেই printf-এ jump করে, dynamic-linker-এর কোনো জড়িত থাকা লাগে না।

প্রথম printf() কল:
  call printf@plt ──▶ jmp *GOT[printf] ──▶ (GOT-এ এখনো resolver-এর ঠিকানা)
                                              │
                                              ▼
                                    dynamic linker (ld.so) চালু হয়
                                    libc.so.6-এ printf খোঁজে
                                    GOT[printf] ← printf-এর প্রকৃত ঠিকানা (patch)
                                              │
                                              ▼
                                    printf-এ jump করে, execute করে

দ্বিতীয় printf() কল (আর পরের সব):
  call printf@plt ──▶ jmp *GOT[printf] ──▶ সরাসরি printf-এ jump (dynamic linker লাগেনি)

এই কৌশলটার নাম lazy binding — যেসব function কখনোই call হয় না (অনেক বড় library-তে সাধারণ), তাদের জন্য কখনোই resolution খরচ হয় না; শুধু যেগুলো সত্যিই ব্যবহৃত হয়, শুধু তাদেরই, আর শুধু একবারই। এটা আগের module-এর memory-hierarchy লেসনের সেই “শুধু যা লাগে, শুধু তখনই” নীতিরই (demand paging-এর অনুরূপ) একটা linking-স্তরের প্রতিফলন।

Section বনাম Segment — linker আর loader দুই ভিন্ন দৃষ্টিভঙ্গিতে একই ELF ফাইল পড়ে

এতক্ষণ যা দেখেছি (.text, .data, .symtab…) — এগুলো section — সূক্ষ্ম-দানার (fine-grained), linker-এর জন্য দরকারি তথ্য (কোন symbol কোথায়, কোন relocation কোথায়)। কিন্তু ELF ফাইলে আরেকটা সম্পূর্ণ আলাদা টেবিল আছে — program header table — যেটা loader-এর জন্য, sections-এর চেয়ে অনেক মোটা-দানার (coarse-grained)। readelf -l (lowercase L) সেটা দেখায়:

readelf -l prog

Program Headers:
  Type           Offset   VirtAddr           FileSiz  MemSiz   Flg
  PHDR           0x000040 0x0000000000000040 0x0002d8 0x0002d8 R
  INTERP         0x000318 0x0000000000000318 0x00001c 0x00001c R
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
  LOAD           0x000000 0x0000000000000000 0x000638 0x000638 R
  LOAD           0x001000 0x0000000000001000 0x000189 0x000189 R E
  LOAD           0x002000 0x0000000000002000 0x0000f0 0x0000f0 R
  LOAD           0x002df0 0x0000000000003df0 0x000228 0x000230 RW
  DYNAMIC        0x002e00 0x0000000000003e00 0x0001d0 0x0001d0 RW

লক্ষ করুন loader-এর কোনো আগ্রহই নেই কোনটা .text না .rodata না .symtab — সে শুধু জানতে চায় কতগুলো contiguous byte-range memory-তে map করতে হবে, কোন permission নিয়ে (R = read-only, R E = read+execute, RW = read+write)। এই কারণেই একাধিক section (যেমন .text আর .rodata, দুটোই read-only) প্রায়ই একটাই LOAD segment-এ একসাথে গুটিয়ে দেওয়া হয় — loader-এর জন্য একটাই mmap()-এর মতো কাজ যথেষ্ট, sections-এর সূক্ষ্ম বিভাজন তার কোনো কাজে লাগে না।