Tôi muốn gỡ lỗi pthreads trên bản phân phối Linux tùy chỉnh của mình nhưng tôi thiếu một số thứ. Máy chủ của tôi là Ubuntu 12.04, mục tiêu của tôi là một Linux nhúng tùy chỉnh i486 được xây dựng với bộ công cụ biên dịch chéo chéo-NG, phần còn lại của hệ điều hành được tạo bằng Buildroot.Tôi cần gì để gỡ lỗi pthreads?
tôi sẽ liệt kê các sự kiện:
tôi có thể chạy các ứng dụng đa luồng dữ liệu trên mục tiêu của tôi
Google Breakpad thất bại trong việc tạo ra một báo cáo tai nạn khi tôi chạy một ứng dụng đa luồng dữ liệu trên các mục tiêu . Ứng dụng tương tự chính xác với cùng một thư viện xây dựng của thư viện Breakpad sẽ thành công khi tôi chạy nó trên máy chủ của tôi.
GDB không gỡ lỗi được các ứng dụng đa luồng trên mục tiêu của tôi.
ví dụ:
$./gdb -n -ex "thread apply all backtrace" ./a.out --pid 716
dlopen failed on 'libthread_db.so.1' - /lib/libthread_db.so.1: undefined symbol: ps_lgetfpregs
GDB will not be able to debug pthreads.
GNU gdb 6.8
Tôi không nghĩ rằng ps_lgetfpregs là một vấn đề vì this.
Công cụ tạo dấu chéo của tôi đã tạo tệp libthread_db.so và tôi đặt nó lên đích.
Công cụ tạo dấu chéo của tôi đã tạo gdb cho mục tiêu của tôi, vì vậy nó phải được liên kết với cùng một thư viện mà tôi chạy trên đích.
Nếu tôi chạy gdb trên máy chủ của mình, so với ứng dụng thử nghiệm của tôi, tôi nhận được một backtrace của mỗi thread đang chạy.
Tôi nghi ngờ vấn đề với Breakpad có liên quan đến vấn đề với GDB, nhưng tôi không thể chứng minh điều này. Tính phổ biến duy nhất là thiếu gỡ lỗi đa luồng.
Có một số khác biệt quan trọng giữa máy chủ và mục tiêu của tôi khiến tôi không thể gỡ lỗi pthreads trên mục tiêu.
Có ai biết nó là gì không?
EDIT:
Denys Dmytriyenko từ TI nói:
Thông thường, GDB không phải là rất kén chọn và bạn có thể trộn và kết hợp phiên bản khác nhau của gdb và gdbserver. Nhưng, thật không may, nếu bạn cần phải debug đa luồng ứng dụng, có một số phụ thuộc cho API cụ thể ...
Ví dụ, đây là một trong những thông điệp bạn có thể thấy nếu bạn không build GDB đúng sự ủng hộ chủ đề:
dlopen thất bại trên 'libthread_db.so.1' - /lib/libthread_db.so.1: biểu tượng không xác định: ps_lgetfpregs GDB sẽ không thể để gỡ lỗi pthreads.
Lưu ý rằng lỗi này giống với lỗi mà tôi nhận được nhưng anh ấy không đi sâu vào chi tiết về cách tạo GDB "đúng".
và GDB FAQ nói:
(Q) GDB không thấy bất kỳ chủ đề bên cạnh một trong đó tai nạn xảy ra; hoặc SIGTRAP giết chương trình của tôi khi tôi đặt điểm ngắt.
(A) Điều này thường xảy ra trên Linux, đặc biệt là trên các mục tiêu được nhúng. Có hai chung nguyên nhân:
bạn đang sử dụng glibc, và bạn đã bị tước libpthread.so.0
không phù hợp giữa libpthread.so.0 và libthread_db.so.1
GDB tự làm không biết cách giải mã "khối điều khiển luồng" được duy trì bởi glibc và được coi là chi tiết triển khai riêng tư glibc. Nó sử dụng libthread_db.so.1 (một phần của glibc) để giúp nó làm như vậy. Do đó, libthread_db.so.1 và libpthread.so.0 phải khớp với phiên bản và cờ tổng hợp. Ngoài ra, libthread_db.so.1 yêu cầu một số biểu tượng không phải là toàn cầu có mặt trong libpthread.so.0, .
Giải pháp: sử dụng dải --strip-debug libpthread.so.0 thay vì dải libpthread.so.0.
Tôi đã thử một libpthread.so.0 không bị tước bỏ nhưng không tạo sự khác biệt. Tôi sẽ điều tra bất kỳ sự không khớp nào giữa pthread và thread_db.
Bạn có đang tung hứng những con thỏ lửa cùng một lúc không? Bạn chắc chắn không muốn làm mọi thứ dễ dàng cho chính mình. –
hahaha, vâng. Chào mừng bạn đến với Linux nhúng nơi không có gì là thẳng về phía trước và bạn phải biết một chút về mọi thứ (nhưng không bao giờ đủ để thực sự có thẩm quyền). –
chỉ ra rằng xây dựng gdb với -static tùy chọn phủ nhận tùy chọn -rdynamic mà dừng thread_db từ việc tìm kiếm các biểu tượng trong gdb tĩnh. Vì vậy, lỗi "biểu tượng không xác định: ps_lgetfpregs" –