1 คะแนน โดย GN⁺ 2024-08-24 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ผู้ใช้ LWN ได้รวบรวม สารบัญชุดบทความลิงเกอร์ 20 ตอน ของ Ian Lance Taylor ที่เดิมกระจัดกระจายไว้ เพื่อให้ติดตามอ่านได้ในครั้งเดียว
  • ต้นฉบับเป็นบทความของ Ian Lance Taylor ผู้เขียนลิงเกอร์ gold และได้นำบทความที่เรียงตามหมายเลขมาจัดกลุ่มใหม่ตามชื่อหัวข้อ เพื่อให้ค้นหาย้อนกลับได้ง่ายขึ้น
  • ช่วงต้นครอบคลุมแนวคิดของลิงเกอร์, ประวัติส่วนตัว, dynamic linking, รูปแบบไฟล์อ็อบเจ็กต์, shared library, ELF symbol, relocation และการปรับแต่ง TLS
  • ช่วงหลังต่อเนื่องไปถึงการตีความ symbol, การเปรียบเทียบ static/dynamic linking, link time optimization, COMDAT, การ instantiate เทมเพลต C++, exception frame และ incremental linking
  • สารบัญและคอมเมนต์เผยแพร่เป็น public domain จึงไม่มีข้อจำกัดในการคัดลอก ใช้งาน หรือสร้างงานดัดแปลง

สารบัญที่รวบรวมชุดบทความลิงเกอร์ 20 ตอนให้อ่านง่ายขึ้น

  • จัดทำ สารบัญที่อ่านต่อเนื่องได้ง่าย สำหรับบทความลิงเกอร์ 20 ตอนของ Ian Lance Taylor
  • เนื่องจากหาเนื้อหาสารบัญที่เชื่อมโยงกันดีทั้งบนบล็อกของ Ian หรือบน LWN ได้ยาก จึงทำสารบัญแยกขึ้นมา
  • URL ของบทความใช้หมายเลขต่อเนื่อง แต่การมีสารบัญที่บอกหัวข้อของแต่ละตอนช่วยให้มองภาพรวมได้ง่าย
  • แต่ละบทความถูกอ้างถึงด้วยหมายเลขเป็นหลัก จึงตั้งชื่อจาก ชื่อ section ของ Ian เป็นส่วนใหญ่

รายการบทความที่รวมไว้

เงื่อนไขการเผยแพร่

  • สารบัญและคอมเมนต์นี้เผยแพร่เป็น public domain
  • ไม่มีข้อจำกัดในการใช้งาน คัดลอก แสดงต่อสาธารณะ หรือสร้างงานดัดแปลง และไม่ต้องขออนุญาตเพิ่มเติม

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 ผลักดันประสิทธิภาพไปจนสุดทาง
    LLD (ส่วนหนึ่งของ LLVM):
    https://llvm.org/devmtg/2017-10/slides/Ueyama-lld.pdf
    ลิงเกอร์ MOLD:
    https://github.com/rui314/mold/blob/main/docs/design.md
    Apple ก็เปิดตัวลิงเกอร์ตัวใหม่ที่อยู่ในระดับใกล้เคียงกับ mold ด้วย การถกเถียงก่อนหน้านี้อยู่ที่นี่: https://news.ycombinator.com/item?id=36218330

    • ทุกครั้งที่เห็นเรื่องนี้ก็ได้แรงบันดาลใจว่า การไล่ล่าประสิทธิภาพแทบไม่มีวันจบ
      LLD ถูกออกแบบมาให้เร็ว และก่อนหน้านั้น Gold ก็เช่นกัน แต่ Mold แซงทั้งสองไปไกลมาก
  • แม้จะเป็นบทความปี [2008] แต่บทความชุดนี้เป็น ข้อมูลล้ำค่าเหมือนทอง จริง ๆ จึงดีใจเสมอที่ได้เห็นกลับขึ้นหน้าแรกของ HN อีกครั้ง

    • เคยได้ยินว่ามีคนแก้บั๊กของลิงเกอร์ แล้วคิดว่า “มันจะยากแค่ไหนกัน” แต่พออ่านบทความนี้แล้วก็เปลี่ยนความคิด
      เป็น คำอธิบายที่ยอดเยี่ยม จริง ๆ
  • บทความชุดนี้เป็นหนึ่งในบทความที่ชอบที่สุด และมีหลายส่วนที่เปิดโลกสำหรับผมเป็นการส่วนตัว
    คิดว่าไม่มีแหล่งข้อมูลไหน ไม่ว่าจะบนอินเทอร์เน็ตหรือที่อื่น ที่ รวบรวมข้อมูลทั้งหมดนี้ไว้ในที่เดียว ได้แบบนี้ ถ้า Ian ทำออกมาเป็นหนังสือคงดีมาก

    • หนังสือชื่อ Linkers and Loaders ของ John R. Levine ก็ค่อนข้างดีเช่นกัน
    • พิมพ์ทั้ง 20 บทเป็น PDF ออกมาแล้ว ตอนนี้เก็บไว้เหมือนเป็นหนังสือส่วนตัว
      แต่ก็ยังอยากให้ Ian มีเวอร์ชันที่ดูทุกบทได้ในหน้าเดียว
  • https://www.airs.com/blog/archives/51
    เป็นเรื่องเกี่ยวกับการทำ pattern matching ในโค้ดแอสเซมบลี แล้วจัดลำดับซีเควนซ์ใหม่หรือนำกลับมาใช้ซ้ำ

  • รวมคอมเมนต์ก่อนหน้า: https://news.ycombinator.com/item?id=27445981

  • เข้าใจว่าทำไม ลิงเกอร์ ถึงเกิดขึ้นในยุคที่หน่วยความจำมีจำกัด
    แต่ก็สงสัยว่าในสภาพแวดล้อมอย่างระบบสมัยใหม่ที่มีหน่วยความจำเหลือเฟือ เรายังจำเป็นต้องมีลิงเกอร์อยู่ไหม อีกอย่าง shared library ก็ดูเหมือนจะเป็น เส้นทางโจมตีซัพพลายเชน แบบเดียวกับการโจมตี xz ที่เพิ่งถูกสกัดเมื่อต้นปีนี้หรือเปล่า

    • รู้ว่าการใช้ flatpak หรือ Docker กำลังเป็นที่นิยม แต่ถึงอย่างนั้นก็ไม่อยากให้ทุกแอป GUI ที่รันอยู่มีอินสแตนซ์ของ Gtk โผล่มาทีละ 30 ตัว
      ยังต้องคำนึงถึงสภาพแวดล้อมอย่าง Raspberry Pi ด้วย มองว่า shared library ไม่น่าจะเป็นเส้นทางโจมตีที่อันตรายไปกว่าตัวแอปเอง ต่อให้ดาวน์โหลดไบนารีแบบ static มาก็ไม่รู้ว่าข้างในมีอะไรอยู่ และก็ไม่รู้เหมือนกันว่าทำไมทุกคนถึงเชื่อใจ Docker image ครึ่งหนึ่งที่ดาวน์โหลดมาใช้ แต่สุดท้ายก็ใช้กันอยู่ดี
    • คอมไพเลอร์ต้องเห็นทั้งโปรแกรมในคราวเดียว หรือไม่ก็ต้องมีวิธีรวมผลลัพธ์จากหลายขั้นตอนการคอมไพล์เข้าด้วยกัน
      ตราบใดที่ไม่ได้ประมวลผลไฟล์ซอร์สทั้งหมดพร้อมกันด้วย build option ที่เหมือนกันทุกประการ ก็ต้องรวมผลลัพธ์เข้าด้วยกัน แม้จะมี LTO สมัยใหม่ คอมไพเลอร์ก็มักไม่ได้เห็นไฟล์ทั้งหมดของโปรแกรมในระดับซอร์สโค้ด และ C library กับ C++ library ก็มักแยกจากกันอยู่ดี ตราบใดที่หลายภาษาไม่ได้สร้างทั้งโปรแกรมด้วยขั้นตอนคอมไพล์และแอสเซมบลีเดียว ก็ต้องมีอะไรบางอย่างมารวมผลลัพธ์เข้าด้วยกัน และสิ่งนั้นก็คือลิงเกอร์ ต่อให้ build ทุกอย่างแบบ static ก็ยังไม่ทำให้ความจำเป็นของ runtime linker หมดไป เว้นแต่จะ hardcode ที่อยู่แน่นอนที่โปรแกรมจะถูกเรียกใช้งาน ซึ่งวิธีนั้นขัดกับเทคนิคความปลอดภัยอย่าง ASLR
    • Static link ก็ยังเป็นการ link อยู่ดี และถ้าจะรวม object file หลายไฟล์เป็น executable ไฟล์เดียว ก็ต้องใช้ลิงเกอร์
      แนวคิดที่ว่าหน่วยความจำและ CPU มีเหลือเฟือนั้น ผมมองว่าเป็นหนึ่งในเหตุผลที่แม้ฮาร์ดแวร์จะเร็วขึ้นหลายลำดับขั้น แต่ประสบการณ์ผู้ใช้กลับไม่ได้ดีขึ้นอย่างเห็นได้ชัด
    • ความอุดมสมบูรณ์ของหน่วยความจำในระบบสมัยใหม่ที่เกิดขึ้นอย่างฉับพลัน ถูก sandbox, packager, library และ framework ไล่ตามทันและใช้จนหมดไปแล้ว
    • ถ้าต้องการให้ build ที่เปลี่ยนโค้ดแค่บรรทัดเดียว เสร็จภายใน 30 นาที ก็จำเป็นต้องมีอะไรบางอย่างคล้ายลิงเกอร์สำหรับจัดการโค้ดที่คอมไพล์แล้วในหน่วยที่เล็กกว่าทั้งโปรแกรม