1 điểm bởi GN⁺ 2024-08-24 | 1 bình luận | Chia sẻ qua WhatsApp
  • Một người dùng LWN đã sắp xếp loạt 20 bài tiểu luận về linker rải rác của Ian Lance Taylor thành mục lục để có thể theo dõi liền mạch
  • Bản gốc là các bài viết của Ian Lance Taylor, tác giả linker gold; các bài vốn được đánh số là chính được gom lại theo tiêu đề mục để dễ tìm hơn
  • Phần đầu đề cập đến khái niệm linker, tiểu sử cá nhân, dynamic linking, định dạng object file, shared library, symbol ELF, relocation và tối ưu hóa TLS
  • Phần sau tiếp tục với phân giải symbol, so sánh static/dynamic linking, link time optimization, COMDAT, khởi tạo template C++, exception frame và incremental linking
  • Mục lục và bình luận được phát hành dưới dạng public domain, không có hạn chế về sao chép, sử dụng hay tạo tác phẩm phái sinh

Mục lục gom lại để dễ tìm loạt 20 bài tiểu luận về linker

  • Sắp xếp loạt 20 bài viết về linker của Ian Lance Taylor thành mục lục dễ đọc liên tục
  • Vì khó tìm được một mục lục được liên kết tốt trên blog của Ian hoặc LWN, mục lục riêng này đã được tạo ra
  • URL các bài viết được đánh số liên tiếp, nhưng một mục lục giúp nhìn nhanh chủ đề của từng bài là rất hữu ích
  • Mỗi bài chỉ được nhắc đến bằng số, nên tiêu đề chủ yếu được xây dựng từ tiêu đề các mục của Ian

Danh sách bài viết được bao gồm

Điều kiện công khai

  • Mục lục và bình luận này được phát hành dưới dạng public domain
  • Không có hạn chế về sử dụng, sao chép, trình diễn, tạo tác phẩm phái sinh và cũng không cần xin phép thêm

1 bình luận

 
GN⁺ 2024-08-24
Ý kiến trên Hacker News
  • Có người đã chia toàn bộ nội dung thành một ebook bằng Calibre recipe và đăng link; mình để lại bản kết quả ở đây cho ai cần
    https://www.mediafire.com/folder/b8fdqx7eqcpdl/linker
    hoặc
    https://0x0.st/Xycy.azw3
    https://0x0.st/Xyct.epub
    https://0x0.st/Xycv.mobi
    https://0x0.st/Xycw.pdf

  • Nhà phát triển từng làm lldmold linker đã đẩy hiệu năng tới mức cực hạn
    LLD (một phần của LLVM):
    https://llvm.org/devmtg/2017-10/slides/Ueyama-lld.pdf
    MOLD linker:
    https://github.com/rui314/mold/blob/main/docs/design.md
    Apple cũng đã công bố một linker mới ở mức tương tự mold; thảo luận trước đó ở đây: https://news.ycombinator.com/item?id=36218330

    • Mỗi lần nhìn vào mấy thứ này lại thấy được truyền cảm hứng rằng theo đuổi hiệu năng thật sự không bao giờ kết thúc
      LLD được thiết kế để nhanh, Gold trước đó cũng vậy, nhưng Mold đã vượt xa cả hai
  • Dù là bài từ [2008], loạt bài này thật sự là tài liệu quý như vàng, nên lúc nào thấy nó quay lại trang nhất HN cũng đều rất đáng mừng

    • Trước đây nghe nói có người sửa bug linker, mình từng nghĩ “khó đến mức nào chứ”, nhưng đọc xong loạt này thì đổi hẳn suy nghĩ
      Đây thật sự là một phần giải thích xuất sắc
  • Đây là một trong những loạt bài mình thích nhất, và cá nhân mình đã được mở mang rất nhiều từ nó
    Mình không nghĩ có tài liệu nào trên Internet hay nơi khác gom toàn bộ thông tin này vào một chỗ như vậy. Ước gì Ian xuất bản nó thành sách

    • Cuốn Linkers and Loaders của John R. Levine cũng khá hay
    • Mình đã in toàn bộ 20 chương ra PDF và giờ giữ nó như một cuốn sách cá nhân
      Dù vậy, vẫn mong Ian có thể cung cấp một phiên bản cho phép xem tất cả các chương trên một trang
  • https://www.airs.com/blog/archives/51
    Nội dung nói về pattern matching trong mã assembly, rồi sắp xếp lại hoặc tái sử dụng các chuỗi lệnh

  • Tổng hợp bình luận trước đây: https://news.ycombinator.com/item?id=27445981

  • Mình hiểu vì sao linker xuất hiện trong thời kỳ bộ nhớ còn hạn chế
    Nhưng mình vẫn thắc mắc liệu trong môi trường hiện đại, nơi bộ nhớ dồi dào hơn nhiều, linker có còn thật sự cần thiết không. Thêm nữa, shared library chẳng phải cũng có thể trở thành một đường tấn công chuỗi cung ứng như vụ tấn công xz bị chặn hồi đầu năm nay sao?

    • Mình biết việc dùng flatpak hay Docker đang là xu hướng, nhưng dù vậy mình vẫn không muốn mỗi ứng dụng GUI chạy lên lại kéo theo 30 instance Gtk.
      Các môi trường như Raspberry Pi cũng vẫn cần được tính đến. Shared library không hẳn là một đường tấn công nguy hiểm hơn bản thân ứng dụng. Ngay cả khi tải một binary tĩnh, bạn cũng đâu biết trong đó có gì, và mình cũng không hiểu vì sao mọi người lại tin tưởng một nửa số Docker image họ tải về dùng, nhưng rồi ai cũng vẫn dùng như thế
    • Hoặc là compiler phải nhìn được toàn bộ chương trình cùng lúc, hoặc phải có cách hợp nhất kết quả của nhiều bước biên dịch khác nhau
      Trừ khi mọi source file đều được xử lý đồng thời với đúng cùng một tùy chọn build, nếu không thì vẫn phải kết hợp các kết quả đầu ra. Ngay cả với LTO hiện đại, compiler thường cũng không thể nhìn thấy tất cả file của chương trình ở mức source code, và thư viện C với thư viện C++ thường là tách riêng. Trừ khi nhiều ngôn ngữ đều biến toàn bộ chương trình thành một bước biên dịch/lắp ráp duy nhất, nếu không vẫn sẽ cần một thứ để hợp nhất các kết quả, và đó chính là linker. Kể cả khi build tĩnh hoàn toàn, nhu cầu về runtime linker cũng không biến mất trừ khi bạn hardcode chính xác địa chỉ mà chương trình sẽ chạy, mà cách đó lại xung đột với các kỹ thuật bảo mật như ASLR
    • Static linking vẫn là linking, và để gộp nhiều object file thành một file thực thi thì vẫn cần linker
      Mình cho rằng kiểu suy nghĩ “bộ nhớ và CPU bây giờ dư dả rồi” là một trong những lý do khiến trải nghiệm người dùng không cải thiện rõ rệt dù phần cứng đã nhanh hơn nhiều bậc độ lớn
    • Sự dư dả bộ nhớ đột ngột của hệ thống hiện đại đã nhanh chóng bị sandbox, packager, library và framework bắt kịp rồi dùng hết
    • Nếu bạn muốn một bản build chỉ đổi một dòng code mà vẫn xong trong vòng 30 phút, thì sẽ cần một thứ gì đó giống linker để xử lý mã đã biên dịch ở đơn vị nhỏ hơn toàn bộ chương trình