2012-04-18 19 views
7

Tôi đang lược tả một ứng dụng C++ sử dụng tính năng hoàn thiện của Linux và tôi đang nhận được biểu đồ luồng kiểm soát tốt đẹp bằng cách sử dụng GProf2dot. Tuy nhiên, một số biểu tượng từ thư viện C (libc6-2.13.so) chiếm một phần đáng kể trong tổng thời gian, nhưng không có trong cạnh.Làm cách nào để nhận được cha mẹ gọi cho các ký hiệu libc6 (ví dụ: _int_malloc) với tính năng hoàn thiện của linux?

Ví dụ:

  • _int_malloc mất 8% thời gian nhưng không có cha mẹ gọi.
  • __strcmp_sse42__cxxabiv1::__si_class_type_info::__do_dyncast cùng mất khoảng 10% thời gian, và có một người gọi tên là 0, trong đó có người gọi 2d6935c, 2cc748c, và 6, mà không có người gọi.

Kết quả là, tôi không thể tìm ra thói quen nào chịu trách nhiệm cho tất cả tính năng truyền động mạnh mẽ và năng động này chỉ bằng cách sử dụng tính năng hoàn hảo. Tuy nhiên, có vẻ như các ký hiệu khác (ví dụ: malloc nhưng không phải là _int_malloc) không có cha mẹ gọi.

Tại sao perf không hiển thị cha mẹ gọi cho _int_malloc? Tại sao tôi không thể tìm thấy người gọi cuối cùng của __do_dyn_cast? Và, có cách nào để tôi sửa đổi thiết lập của mình để tôi có thể nhận được thông tin này không? Tôi đang trên x86-64, vì vậy tôi tự hỏi nếu tôi cần một libc6 (không chuẩn) với các con trỏ khung.

+0

+1 cho MCMC và chào mừng bạn đến với SO. –

Trả lời

5

Cập nhật: Tính đến kernel 3.7.0, người ta có thể xác định cha mẹ gọi của các biểu tượng trong thư viện hệ thống sử dụng perf record -gdwarf <command>.

Sử dụng -gdwarf, không cần biên dịch với -fno-omit-frame-pointer.

câu trả lời gốc: Vâng, một có lẽ sẽ cần một libc6 biên soạn với con trỏ khung (-fno-omit-framepointer) trên x86_64, tại thời điểm này (ngày 24 Tháng Năm 2012).

Tuy nhiên, nhà phát triển hiện đang làm việc để cho phép các công cụ hoàn thiện sử dụng thông tin thư giãn của DWARF. Điều này có nghĩa là các con trỏ khung không còn cần thiết để lấy thông tin backtrace trên x86_64 nữa. Linus, tuy nhiên, không muốn một DWARF unwinder trong kernel. Do đó, các công cụ perf sẽ lưu các thanh ghi khi hệ thống đang chạy, và thực hiện việc giải nén DWARF trong công cụ perfeless userspace bằng thư viện libunwind.

Kỹ thuật này đã được thử nghiệm để xác định thành công người gọi (ví dụ) mallocdynamic_cast. Tuy nhiên, tập bản vá chưa được tích hợp vào nhân Linux, và cần phải trải qua quá trình sửa đổi trước khi nó sẵn sàng.

+0

Cảm ơn. Trên máy tính của tôi '--call-graph dwarf' là cần thiết thay vì' -gdwarf' – Lack

1

_int_malloc__do_dyn_cast đang được gọi từ các thói quen mà trình hồ sơ không thể xác định vì nó không có thông tin bảng biểu tượng cho chúng.

Còn gì nữa, có vẻ như bạn đang hiển thị thời gian tự (độc quyền). Điều đó chỉ hữu ích cho việc tìm các điểm nóng trong các thói quen mà a) có nhiều thời gian tự, và b) bạn có thể sửa chữa.

Có lý do khiến các trình biên dịch tiếp theo với bản gốc unix profil được tạo. Phần mềm thực bao gồm các chức năng dành gần như toàn bộ thời gian gọi các chức năng khác, và bạn cần có khả năng tìm mã có trên stack nhiều thời gian, không phải chương trình có phần lớn thời gian.

Vì vậy, bạn cần phải định cấu hình perf để lấy mẫu ngăn xếp và cho bạn biết phần trăm thời gian mỗi các thói quen của bạn đang ở trên ngăn xếp. Nó thậm chí còn tốt hơn nếu nó báo cáo không chỉ các thói quen, mà là các dòng mã, như trong Zoom. Tốt nhất là lấy mẫu trên đồng hồ treo tường, vì vậy bạn không bị mù với IO.

There's more to say on all this.

+0

Cảm ơn Mike. Tôi có cả thời gian và thời gian người gọi (tôi đã sử dụng bản ghi âm -g để nhận các cuộc gọi ngăn xếp). Tôi không thể làm nhiều về thời gian thực hiện phôi năng động (hiện g + thực sự so sánh typeinfo với strcmp ??) nhưng tôi có kế hoạch để đảm bảo đúc ít năng động (và cấp phát bộ nhớ) được thực hiện. Để làm điều này nó sẽ được tốt đẹp để biết những gì đang gọi các chức năng đúc động và malloc. – BenRI

+0

Cảm ơn Mike. Tôi có cả thời gian và thời gian người gọi (tôi đã sử dụng bản ghi âm -g). Rõ ràng tôi không thể làm cho malloc hoặc dynamic_cast nhanh hơn nhiều, vì vậy tôi đang cố gắng tìm những thói quen nào đang gọi chúng và sửa chữa những kẻ phạm tội tệ nhất trước. Tôi nghĩ rằng vấn đề là hạt nhân có thể gặp khó khăn khi mở khung chồng trong một số trường hợp (lưu ý, không phải tất cả các trường hợp) và tôi tò mò tại sao hạt nhân không giải phóng stack và tìm người gọi (nói) __strcmp_sse_42. Tôi ** nghi ngờ ** rằng điều này đang được sử dụng để so sánh các đối tượng typeinfo, nhưng không biết người gọi, thật khó để chắc chắn. – BenRI

+1

@BenRI: Liên kết đó thảo luận về cách tôi làm điều đó và * [liên kết này] (http://sourceforge.net/projects/randompausedemo/files/) * có một trình chiếu ngắn về nhận được tỷ lệ tăng tốc tổng thể khoảng 700x bởi tìm và sửa chữa một loạt các vấn đề thuộc loại đó. –