libc 및 libstdc ++ 기호에 대해 Linux 'perf record'를 작동시키는 방법은 무엇입니까?


12

내가 사용하고 perf record -g있는 프로그램을 프로파일 - 64 리눅스에서. libc 또는 libstdc ++의 여러 기호 0는 부모로서 __GI___strcmp_ssse3(libc) 및 strcmp@plt(libstdc ++)를 갖습니다 . (실제로 디버거에서 이러한 기호를 깨고 역 추적을 얻을 수 있습니다.)

이 함수의 주요 호출자가 무엇인지, 왜 기록되지 않는지 알고 싶습니다. libc와 libstdc ++에는 x86_64에 프레임 포인터가 없기 때문에 이것이 있습니까? 그리고 좀 더 실질적으로이 문제를 해결할 방법이 있습니까?

답변:


5

이것은 오래된 질문이지만 지금은 가능합니다 --call-graph dwarf. 매뉴얼 페이지에서 :

 -g
       Enables call-graph (stack chain/backtrace) recording.

   --call-graph
       Setup and enable call-graph (stack chain/backtrace) recording, implies -g.

           Allows specifying "fp" (frame pointer) or "dwarf"
           (DWARF's CFI - Call Frame Information) as the method to collect
           the information used to show the call graphs.

           In some systems, where binaries are build with gcc
           --fomit-frame-pointer, using the "fp" method will produce bogus
           call graphs, using "dwarf", if available (perf tools linked to
           the libunwind library) should be used instead.

나는 이것이 다소 최근의 리눅스 커널을 필요로한다고 생각한다 (> = 3.9? 나는 확실하지 않다). 배포판의 perf 패키지가 libdw 또는 libunwind와 연결되어 있는지 확인할 수 있습니다 readelf -d $(which perf) | grep -e libdw -e libunwind. Fedora 20에서 perf는 libdw와 연결되어 있습니다.


perf record --call-graph dwarf나를 위해이 문제를 해결합니다. 불행히도, 왜소한 정보를 사용할 때 perf는 호출자 기반 (즉, "반전 된") 호출 그래프를 표시하는 데 문제가있는 것 같습니다. 그렇기 때문에 시각화를 위해 FlameGraph를 사용하기 시작했습니다.
blue

드워프 해제를 사용하면 프로파일 링 중 매우 많은 오버 헤드가 발생합니다.
Azsgy

-2

perf시스템 호출의 경과 시간을 표시하는 커널 도구입니다. GNU gprof를 찾고 있습니다. "gprof-통화 그래프 프로파일 데이터 표시". gprof를 사용하려면 -pg스위치 를 사용하여 소스를 컴파일해야합니다 .

이 외에도와 같은 정교한 프로파일 링 도구가 많이 eclipse-cdt-profiling-framework있습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.