Câu trả lời:
Nếu bạn đang chạy trên Linux, hãy sử dụng objdump --debugging
. Cần có một mục nhập cho mỗi tệp đối tượng trong thư viện. Đối với các tệp đối tượng không có ký hiệu gỡ lỗi, bạn sẽ thấy một cái gì đó như:
objdump --debugging libvoidincr.a
In archive libvoidincr.a:
voidincr.o: file format elf64-x86-64
Nếu có các ký hiệu gỡ lỗi, đầu ra sẽ dài dòng hơn nhiều.
objdump -g
không mang lại gì cho tôi cho một bài kiểm tra đơn giản. do đó được biên dịch cả có lẫn không g
, khiến nó trở nên vô dụng một cách hiệu quả. Ubuntu 12.04, gcc 4.6.3, GNU objdump 2.22. nm -a
có vẻ hữu ích hơn.
Lệnh gợi ý
objdump --debugging libinspected.a
objdump --debugging libinspected.so
cho tôi kết quả luôn giống nhau ít nhất là trên Ubuntu / Linaro 4.5.2:
libinspected.a: file format elf64-x86-64
libinspected.so: file format elf64-x86-64
cho dù thư viện lưu trữ / chia sẻ được xây dựng có hay không có -g
tùy chọn
Điều gì thực sự đã giúp tôi để xác định liệu -g
được sử dụng là readelf công cụ:
readelf --debug-dump=decodedline libinspected.so
hoặc là
readelf --debug-dump=line libinspected.so
Thao tác này sẽ in ra tập hợp các dòng bao gồm tên tệp nguồn, số dòng và địa chỉ nếu thông tin gỡ lỗi đó được đưa vào thư viện , nếu không, nó sẽ không in gì .
Bạn có thể chuyển bất kỳ giá trị nào bạn thấy cần thiết cho --debug-dump
tùy chọn thay vì decodedline
.
Những gì đã giúp là:
gdb mylib.so
Nó sẽ in khi không tìm thấy ký hiệu gỡ lỗi:
Reading symbols from mylib.so...(no debugging symbols found)...done.
Hoặc khi tìm thấy:
Reading symbols from mylib.so...done.
Không có câu trả lời nào trước đó mang lại kết quả có ý nghĩa cho tôi: các lib không có ký hiệu gỡ lỗi đang đưa ra nhiều kết quả, v.v.
nm -a <lib>
sẽ in tất cả các ký hiệu từ thư viện, bao gồm cả các ký hiệu gỡ lỗi.
Vì vậy, bạn có thể so sánh kết quả đầu ra của nm <lib>
và nm -a <lib>
- nếu chúng khác nhau, lib của bạn chứa một số ký hiệu gỡ lỗi.
nm -a
có bí danh nm --debug-syms
tự giải thích :-).
diff <(nm <lib>) <(nm -a <lib>)
để nhận được sự khác biệt dễ dàng
Trên OSX, bạn có thể sử dụng dsymutil -s
và dwarfdump
.
Sử dụng, dsymutil -s <lib_file> | more
bạn sẽ thấy các đường dẫn tệp nguồn trong các tệp có ký hiệu gỡ lỗi, nhưng chỉ có tên hàm khác.
dsymutil -s
không? Sự tồn tại của đầu ra có nghĩa là nó đã được xây dựng với các ký hiệu gỡ lỗi, hay nó phải được gắn vào?
Các câu trả lời đề xuất việc sử dụng objdump --debugging
hoặc readelf --debug-dump=...
không hoạt động trong trường hợp thông tin gỡ lỗi được lưu trữ trong tệp tách biệt với tệp nhị phân, tức là tệp nhị phân chứa phần liên kết gỡ lỗi . Có lẽ người ta có thể gọi đó là một lỗi trong readelf
.
Đoạn mã sau sẽ xử lý điều này một cách chính xác:
# Test whether debug information is available for a given binary
has_debug_info() {
readelf -S "$1" | grep -q " \(.debug_info\)\|\(.gnu_debuglink\) "
}
Xem Tệp gỡ lỗi riêng biệt trong hướng dẫn sử dụng GDB để biết thêm thông tin.
obdjump -W lib
vàreadelf -w lib
. Cái sau có thể định cấu hình cao hơn - xem readelf (1) manpage.