1 पॉइंट द्वारा GN⁺ 2024-08-24 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • बिखरे हुए Ian Lance Taylor के 20-भाग वाले लिंकर निबंध को एक साथ पढ़ने में आसान बनाने के लिए LWN यूज़र ने इसे विषय-सूची के रूप में व्यवस्थित किया
  • मूल लेख gold लिंकर के लेखक Ian Lance Taylor के हैं, और नंबर-आधारित पोस्टों को सेक्शन शीर्षकों के आधार पर फिर से इस तरह समूहित किया गया है कि उन्हें ढूंढना आसान हो
  • शुरुआती हिस्सा लिंकर की अवधारणा, व्यक्तिगत इतिहास, dynamic linking, object file formats, shared libraries, ELF symbols, relocation, और TLS optimization तक कवर करता है
  • बाद का हिस्सा symbol resolution, static/dynamic linking की तुलना, link time optimization, COMDAT, C++ template instantiation, exception frames, और incremental linking तक जाता है
  • विषय-सूची और कमेंट्स public domain में जारी किए गए हैं, इसलिए कॉपी, उपयोग और derivative works पर कोई प्रतिबंध नहीं है

20-भाग वाले लिंकर निबंध को आसानी से खोजने योग्य बनाने वाली विषय-सूची

  • Ian Lance Taylor की 20-भाग वाली लिंकर पोस्टों को लगातार पढ़ने में आसान विषय-सूची के रूप में व्यवस्थित किया गया
  • Ian के ब्लॉग या LWN पर अच्छी तरह लिंक की गई विषय-सूची मिलना मुश्किल था, इसलिए अलग से यह विषय-सूची बनाई गई
  • पोस्टों के URL क्रमिक नंबरों वाले हैं, लेकिन हर पोस्ट का विषय एक नजर में देखने के लिए विषय-सूची उपयोगी है
  • हर पोस्ट को केवल नंबर से संदर्भित किया गया है, इसलिए शीर्षक मुख्य रूप से Ian के सेक्शन शीर्षकों से लेकर बनाए गए हैं

शामिल लेखों की सूची

सार्वजनिक शर्तें

  • यह विषय-सूची और कमेंट्स public domain में जारी किए गए हैं
  • उपयोग, कॉपी, प्रदर्शन, और derivative works बनाने पर कोई प्रतिबंध नहीं है और अतिरिक्त अनुमति की जरूरत भी नहीं है

1 टिप्पणियां

 
GN⁺ 2024-08-24
Hacker News की राय
  • किसी ने Calibre recipe के साथ पूरी सामग्री को एक ही ई-बुक में बाँधकर उसका लिंक दिया था, इसलिए जिन्हें ज़रूरत हो उनके लिए नतीजा यहाँ रखा गया है
    https://www.mediafire.com/folder/b8fdqx7eqcpdl/linker
    या
    https://0x0.st/Xycy.azw3
    https://0x0.st/Xyct.epub
    https://0x0.st/Xycv.mobi
    https://0x0.st/Xycw.pdf

    • थोड़ा अफसोस है कि इसमें टिप्पणियाँ भी शामिल हैं, इसलिए पेजों की संख्या काफ़ी बढ़ जाती है
    • archive.org पर भी फ़ाइलें मौजूद हैं: https://archive.org/details/linkers.-ian.-lance.-taylor
  • lld और mold linker पर काम करने वाले डेवलपर ने performance को हद तक आगे बढ़ा दिया
    LLD (LLVM का हिस्सा):
    https://llvm.org/devmtg/2017-10/slides/Ueyama-lld.pdf
    MOLD linker:
    https://github.com/rui314/mold/blob/main/docs/design.md
    Apple ने भी mold के समान स्तर का एक नया linker जारी किया है, उसकी पिछली चर्चा यहाँ है: https://news.ycombinator.com/item?id=36218330

    • इसे हर बार देखकर performance की खोज शायद कभी ख़त्म नहीं होती जैसी प्रेरणा मिलती है
      LLD को तेज़ बनाने के लिए डिज़ाइन किया गया था, उससे पहले Gold भी ऐसा ही था, लेकिन Mold ने दोनों को काफ़ी पीछे छोड़ दिया
  • यह [2008] की पोस्ट है, लेकिन ये लेख सचमुच सोने जैसी सामग्री हैं, इसलिए HN के पहले पेज पर इन्हें फिर देखना हमेशा अच्छा लगता है

    • जब सुना कि किसी ने linker bug ठीक किया है, तो पहले लगा “इसमें कितना मुश्किल होगा”, लेकिन यह लेख पढ़कर सोच बदल गई
      यह सच में शानदार व्याख्या है
  • यह लेख-श्रृंखला मेरी पसंदीदा में से एक है, और निजी तौर पर इसने मेरी समझ कई बार बदली
    मुझे नहीं लगता कि इंटरनेट या कहीं और यह सारी जानकारी एक जगह इकट्ठी करने वाला कोई और संसाधन है। काश Ian ने इसे किताब के रूप में प्रकाशित किया होता

    • John R. Levine की Linkers and Loaders नाम की किताब भी काफ़ी अच्छी है
    • मैंने सभी 20 अध्याय PDF में प्रिंट करके अब उसे लगभग अपनी निजी किताब की तरह रखा हुआ है
      बस इच्छा है कि Ian सभी अध्यायों को एक ही पेज पर देखने वाला कोई संस्करण भी दे देते
  • https://www.airs.com/blog/archives/51
    इसमें assembly code में pattern matching करने, और sequences को फिर से व्यवस्थित या पुन: उपयोग करने की बात है

  • पिछली टिप्पणियों का संकलन: https://news.ycombinator.com/item?id=27445981

  • यह समझ आता है कि जब memory सीमित थी तब linker क्यों बना
    लेकिन जिज्ञासा है कि आज के memory-समृद्ध सिस्टमों में भी linker की ज़रूरत क्यों बनी हुई है। साथ ही, shared libraries क्या इस साल की शुरुआत में रोके गए xz हमले की तरह supply-chain attack का रास्ता नहीं बनतीं?

    • मुझे पता है कि flatpak या Docker जैसी चीज़ों का इस्तेमाल चलन में है, लेकिन फिर भी मैं नहीं चाहूँगा कि हर GUI app के साथ Gtk के 30 instances चलें
      Raspberry Pi जैसे environment भी अभी भी ध्यान में रखने पड़ते हैं। shared libraries को app से ज़्यादा ख़तरनाक attack vector मानना ठीक नहीं होगा। अगर आप static binaries डाउनलोड करें तो भी अंदर क्या है, यह पता नहीं चलता, और लोग जो Docker images डाउनलोड करके चलाते हैं, उनमें से आधों पर भरोसा क्यों करते हैं यह भी समझ नहीं आता, फिर भी लोग ऐसा करते हैं
    • या तो compiler को पूरे program को एक साथ देखना होगा, या फिर कई compilation चरणों के परिणामों को जोड़ने का कोई तरीका चाहिए
      जब तक आप सभी source files को एक साथ और बिल्कुल समान build options के साथ प्रोसेस नहीं करते, तब तक outputs को जोड़ना पड़ेगा। आधुनिक LTO होने पर भी compiler आम तौर पर program की सभी files को source-code स्तर पर नहीं देख पाता, और C libraries तथा C++ libraries अक्सर अलग होती हैं। जब तक कई भाषाएँ पूरे program को एक ही compilation-assembly चरण में नहीं बदलतीं, तब तक outputs को जोड़ने के लिए कुछ चाहिए, और वही linker है। सब कुछ statically build करने पर भी, जब तक program के चलने के सही addresses को hardcode न कर दिया जाए, runtime linker की ज़रूरत ख़त्म नहीं होती, और ऐसा करना ASLR जैसी security techniques से टकराता है
    • Static linking भी linking ही है, और कई object files को एक executable में जोड़ने के लिए linker चाहिए
      memory और CPU बहुत हैं वाली सोच शायद उन कारणों में से एक है जिनकी वजह से hardware कई orders of magnitude तेज़ होने के बावजूद user experience उतना बेहतर महसूस नहीं होता
    • आधुनिक सिस्टमों में memory की अचानक आई प्रचुरता को sandbox, packagers, libraries और frameworks ने पूरी तरह खपा लिया है
    • अगर आप चाहते हैं कि code की सिर्फ एक line बदलने वाला build 30 मिनट के भीतर पूरा हो जाए, तो पूरे program से छोटे स्तर पर compiled code को संभालने के लिए linker जैसी किसी चीज़ की ज़रूरत होगी