실제 이렇게 줄어든 바이너리의 크기는 그렇지 않은 것에 비하여 2~3배
정도 차이가 나게 됩니다.
아래의 예제는 이번 테스트에서 이용한 실행 파일의 크기를 비교한 것입니다.
문제는 이렇게 strip한 바이너리를 수행하다가 예기치 않은 오류로 core 파일만을 남겨두고 장렬히 전사(?)한 경우에도,
gdb로 core와 바이너리를 가지고 back trace해보면, Symbol('??'로 표시됨)이 다 생략되어서 나오게 됩니다.
개발자 입장에서 문제는 있다고 하는데, 어떤 부분이 문제가 되고 있는지 gdb가 알려주지 않기 때문에 참 난감한 상황입니다. 이에 대한 해결방법으로 ‘strip으로 symbol이 없는 바이너리'가 생성한 core 파일과 ‘symbol을 모두 가지고 있는 바이너리’ – (이하 ‘symbol 바이너리’ 라고 하겠습니다.)를 이용하여 gdb에 load하는 방법이 있습니다.
gdb에 실행 바이너리와 core 파일을 load시, core 파일은 ‘최적화된 바이너리’ 생성된 것을, 실행 바이너리는 ‘최적화된 바이너리’ 대신에 ‘symbol 바이너리’를 load합니다. 이런 경우 아래의 그림에서 확인할 수 있듯이, back trace도 가능하고, 각 변수의 값과 code도 확인이 가능합니다.
이때 주의할 내용으로 두 바이너리의 최적화 옵션은 동일해야
합니다.
예를 들어, ‘strip된 바이너리’에서 ‘-O2’를 사용하는 경우, ‘symbol
바이너리’에서도 이 옵셥을 build시 사용해야
합니다.
[Postscript]
Network이 연결되는 환경이라면 NFS로 타겟의 mount point를 host PC로 만드는 것도 좋은 방법입니다.
대신 저는 그렇게 작업을 하면 Target에서 직접 실행하는 것보다 꽤 실행 속도가 저하되는 것을 느꼈습니다.
