나는 다른 시스템에서 필요로하는 모든 응용 프로그램을 컴파일해야하는 리눅스 시스템을 제거했습니다. 이러한 응용 프로그램 코어는 종종 핵심 정보와 그로부터 얻을 수있는 유일한 정보는 코어링 된 기능과 명령 오프셋입니다. 다른 옵션이없는 경우 실행 파일에 objdump를 수행하고 명령 오프셋 및 어셈블리 조각에서 소스 코드를 추측 해보십시오. 내 인생이야.C++ 코어 덤프에서 소스 행 번호를 추론
참고 : g ++를 사용하여 응용 프로그램을 크로스 컴파일하고 제거합니다. 그래서 gdb가 많이 도와주지 않았다.
질문 : 컴파일러/gcc가 소스 라인을 어셈블리 명령어로 변환 했으므로 명령어 오프셋과 라인 사이의 상관 관계를 제공하는 옵션이 없습니까?
-g으로 빌드를 만든 다음 심볼 맵을 가져옵니다. 그것을 저장 어딘가에 (나는 디버깅 기호로 바이너리를 저장하는 것이 좋습니다 - 그렇게 쉬운 방법입니다), 그리고 디버그 심볼을 제거하고 (strip 프로그램으로) 결과 바이너리를 대상 시스템에 배포하십시오. https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html
오류가 발생한 후 -g- 컴파일 된 바이너리 또는 릴리스 바이너리와 별도의 디버그 파일로 덤프를 복원하십시오. 디버깅 기호로 충돌 주소 및 바이너리가 있고 소스 코드 줄에 매핑하려는 경우 gdb 대신 addr2line -e your_binary crash_address을 사용할 수 있습니다.
-g 플래그로 소스 코드를 컴파일해야 디버그 정보를 사용할 수 있으며 요청한 상관 관계를 정확하게 제공해야합니다.
그런 다음 응용 프로그램이 충돌하는 경우 gdb에서 실행하고 충돌이 발생할 때 프로그램 상태를 검사 할 수 있습니다.
스트립되지 않은 바이너리를 사용하여 코어 파일 (스트립 된 바이너리에 의해 생성 된)을 디버깅하는 경우 라인/파일 정보를 얻을 수 있습니다.