libtool gdb 속도 저하

디버깅 할 템플릿이 많은 C++ 프로그램이 더 있습니다. 불행히도 gdb는 심볼을 읽는 데 몇 분이 걸립니다.libtool gdb 속도 저하

http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html에는 디버깅 옵션이 많이 포함되어 있습니다.

gdb를 더 빠르게 /보다 유용하게 만들려면 어떤 옵션을 제안 하시겠습니까?

업데이트 : 속도 저하가 libtool에 의한 것 같습니다. gdb가 libtool --mode를 통해 실행되면 실행 속도가 느립니다. gdb가 시작되면 gdb .libs/foo가 빠르다. 왜 어떤 아이디어가 더 느린가요?

업데이트 : 또 다른 제안 -fvisibility = 볼 숨겨진

출처

2014-03-04 arved

GDB 인덱스 (https://sourceware.org/gdb/onlinedocs/gdb/Index-Files.html)에 언급되지 않은 점이 놀랍습니다. 첫 번째 디버그 심볼로드는 평소와 같이 느려지지만 'save gdb-index' 명령과 일부 objcopy 마술을 사용하면 _subsequent_ 디버그 심볼로드 시간을 크게 단축 할 수 있습니다. 디버그 심볼을 가진 바이너리가 생성 된 후에는 빌드 모드에서 GDB를 실행하여 생성 된 인덱스를 생성하고 신속하게로드 할 수있는 디버깅이 가능한 바이너리를 생성한다. 특히 빌드 머신에 포함시키는 것이 좋습니다. –

http://gcc.gnu.org/wiki/Visibility 때로는 조금 더 빨리 일을 할 수 -fdebug-유형 섹션을 사용하여. 그것은 비록 보장되지 않습니다.

로드하는 데 몇 분 ...이 실행 파일이 얼마나 큰지 궁금합니다. 절망적 인 경우 디버그 정보를 사용하여 선택한 모듈 만 컴파일 할 수도 있습니다. 또는 아마도 gdb 버그인지 확인하십시오. 실행 파일과 일부 공유 라이브러리로 분할되어 있고 일부가 자주 변경되지 않는 경우 "gdb 인덱스"기능 (매뉴얼 참조)을 사용하여 해당 모듈에 대한 debuginfo의로드 속도를 높일 수 있습니다.

출처

2014-03-05 00:09:45

-fdebug-types-section이 차이를 만들지 않았습니다. 실행 파일은 ca입니다. 18MB가 스트립되지 않고 3.2MB가 제거되었습니다. gdb 버전은 7.7입니다. 차이점을 확인하려면 git에서 버전으로 업그레이드하려고 시도 할 것입니다. – arved

7,7은 새로운 차이점이 있으므로 많은 차이가 없을 것입니다. 그건 나에게 너무 큰 소리는 아니지만, 몇 분이면 놀랍습니다. –

libtool --mode execute를 통해 gdb를 실행하면 느려지는 것처럼 보입니다. (업데이트 참조) – arved

답변

관련 문제