2013-12-11 2 views
0

다소 크고 복잡한 프로젝트를 인수했습니다. 그것의 일부는 Xcode 파일 (사실 CMake에 의해 생성 된 ...)에 의해 생성 된 정적 (C++) 라이브러리입니다.Xcode 디버거가 내 파일을 찾지 못했습니다.

응용 프로그램 자체는 완전히 다른 프로젝트에 있습니다.

앱을 디버깅하고 라이브러리로 들어가려면 어셈블리 만 표시됩니다. 모든 심볼이 거기에있는 것처럼 보입니다. 출력은 MyApp'Foo::bar(char const*) at Foo.cpp:102:으로 시작되며, 다음과 같은 것을 볼 수 있습니다. 0x1507a6: bl 0x150838 ; Foo::fazbar(int) at Foo.cpp:206

이것은 상징화가 있고 실제로 작동한다고 말합니다.

이제 Foo.cpp가 내 컴퓨터에 있습니다. 나는 그 파일을 열 수 있고 실제로 206 행의 Foo :: fazbar가 호출된다.

nmotool의 출력이 의심스럽지 않습니다.

lldb (Xcode의 디버거)가 내 파일을 찾지 못하는 이유는 무엇입니까? 파일이있는 곳을 lldb에게 어떻게 알릴 수 있습니까?

모든 포인터가 감사하겠습니다.

+0

lldb의 이미지 검색 --address --verbose를 사용하면 "Module : file"은 정확하지만 "CompileUnit :"은 완전히 잘못된 주소임을 알 수 있습니다. 나는 조사 할 것이다 – below

+1

Mac OS X의 두 장소에 디버그 정보가 존재한다 : 오브젝트 파일 ('.o' 파일)과 dSYM 번들 ('.dSYM')에있다. 프로그램을 컴파일하고 테스트 할 때 Xcode는 보통 디버깅 정보를'.o' 파일에 남겨 둡니다. 바이너리를 마무리 할 시간이되면 일반적으로 모든 디버그 정보를 한 곳에 저장하도록'.dSYM '이 생성됩니다. 정적 라이브러리 (ranlib archive)는'.o' 파일의 모음입니다. '.a' lib에 링크하는 바이너리는 사용 된 모든 디버그 정보를'.dSYM'에 복사합니다. 그래서'.dSYM'을 찾으십시오. 그리고'.a'lib ('ar x libname.a')를'dwarfdump'로'.o' 파일을 보면서 시도해보십시오. –

답변

1

라이브러리를 빌드했을 때와 비교하여 소스 파일을 옮겼습니까?

+0

아니요, 코드는 그 위치에 그대로있었습니다. 실제로 라이브러리의 바이너리 그곳에 있던 곳에서 바로 머무르다. – below

+0

문제는 잘못된 바이너리가 링크 된 것인데, 다른 누군가의 머신에 대한 경로가 포함되어있다. 정확한 바이너리를 넣으면 문제가 해결되었다. – below