Tại sao cả thư viện glibc và pthread đều được định nghĩa cùng một API?

Question

Tại sao cả thư viện glibc và pthread đều được định nghĩa cùng một API? Dưới đây là ảnh chụp

ubuntu@ubuntu:/lib$ objdump -T /lib/i386-linux-gnu/libc.so.6 |grep pthread_cond_signal 
000f8360 g DF .text 00000039 GLIBC_2.3.2 pthread_cond_signal 
0012b940 g DF .text 00000039 (GLIBC_2.0) pthread_cond_signal 

ubuntu@ubuntu:/lib$ objdump -T /lib/i386-linux-gnu/libpthread.so.0 |grep pthread_cond_signal 
0000b350 g DF .text 0000007c (GLIBC_2.0) pthread_cond_signal 
0000af90 g DF .text 000000fc GLIBC_2.3.2 pthread_cond_signal 

Answer 1

libpthread.so là một phần của glibc quá, và cả hai đều chứa (giống hệt nhau) định nghĩa của một số biểu tượng.

Nếu bạn tìm kiếm pthread_create thay vào đó bạn sẽ thấy rằng nó chỉ hiện diện trong libpthread.so - điều này có nghĩa là chương trình phải liên kết đến libpthread.so để thực sự tạo chủ đề , nhưng có thể sử dụng mutexes và các biến điều kiện trong các chương trình đơn luồng mà chỉ liên kết đến libc.so. Đó là hữu ích cho mutexes interprocess và biến điều kiện interprocess sống trong bộ nhớ chia sẻ và được sử dụng để đồng bộ hóa với các quá trình riêng biệt . (chỉnh sửa nhờ bình luận của Zan Lynx bên dưới).

Nó không phải là một vấn đề liên kết với cả hai libpthread.so và libc.so mặc dù cả hai đều xác định biểu tượng. Các liên kết ELF cho phép một số thư viện chia sẻ chứa các định nghĩa của cùng một biểu tượng và trình liên kết sẽ chọn định dạng đầu tiên mà nó nhìn thấy và sử dụng nó cho tất cả các tham chiếu đến biểu tượng đó, được gọi là symbol interposition. Một tính năng khác cho phép nhiều biểu tượng được xác định là nếu một thư viện chứa weak symbols sẽ được ghi đè bởi các ký hiệu không yếu có cùng tên. Trong trường hợp này, các định nghĩa trong hai thư viện giống hệt nhau, do đó, việc sử dụng libpthread.so ghi đè những số này trong libc.so là không quan trọng. Nếu bạn sử dụng LD_DEBUG và thay đổi thứ tự của các đối số cho trình liên kết bạn sẽ có thể thấy thư viện nào thực sự được tìm thấy biểu tượng.

Cũng như hai thư viện xác định cùng một biểu tượng, mỗi thư viện có hai định nghĩa biểu tượng, với khác nhau symbol versions, GLIBC_2.0 và GLIBC_2.3.2. Phiên bản biểu tượng này cho phép nhiều định nghĩa cùng tồn tại trong cùng một thư viện sao cho các phiên bản mới, được cải tiến của hàm được thêm vào thư viện mà không phá vỡ mã được liên kết với việc thực thi cũ. Điều này cho phép cùng một thư viện được chia sẻ để làm việc cho các ứng dụng sử dụng LinuxThread và các ứng dụng sử dụng NPTL. Biểu tượng mặc định mà tham chiếu sẽ bị ràng buộc khi liên kết đến thư viện là pthread_cond_signal@GLIBC_2.3.2 tương ứng với việc thực hiện NPTL của hàm đó (NPTL lần đầu tiên được bao gồm trong glibc 2.3.2). Biểu tượng cũ hơn, pthread_cond_signal@GLIBC_2.0, là phiên bản LinuxThreads cũ hơn đã được mặc định trước khi NPTL được cung cấp. Các ứng dụng được liên kết với các phiên bản glibc cũ hơn (trước 2.3.2) sẽ bị ràng buộc với pthread_cond_signal@GLIBC_2.0 và sẽ sử dụng biểu tượng đó.