다음을 포함하는 컴파일된 공유 라이브러리가 있습니다 -g -O0
.
void MyClass::whatever()
{
...
doSomething(myImage, myPoints);
...
}
bool MyClass::doSomething(const Image& image, std::vector<cv::Vec2f>& points) const
{
const int32_t foo = 1;
const float bar = 0.1f;
...
}
이제 나는 그것을 밟고 있지만 whatever()
, s
그 안으로 들어가는 대신에 doSomething()
그것을 넘어서고 있습니다. (1) 동일한 파일에 있고 (2) 중단점을 설정 doSomething()
하고 문제 없이 소스를 단계별로 진행할 수 있기 때문에 소스 가용성 문제는 아닙니다 . 그러나 s
사용 가능한 소스가 없다고 생각되는 것 같습니다.
I 경우 set step-mode on
다음과 같은 출력을 얻습니다.
0xb5d51148 in myClass::doSomething (this=0xb25e4, image=...,
points=std::vector of length -91315, capacity 372871920 = {...})
from /path/to/myclass.so
사용 가능한 소스가 없을 때 얻는 것과 같습니다. 여러 번의 초기화 후에 소스 코드가 표시 n
됩니다 foo
. 따라서 inline
함수 시작 부분에 배치된 매개변수(유형, 릴리스 버전)에는 마법이 있을 수 있습니다. 이것을 보고 "이상한 일이군요. 이 함수 다음으로 넘어가겠습니다"라고 생각하고 대부분의 함수에 실제로 사용 가능한 소스 코드가 있다는 것을 알지 못하는 것이 opencv
가능합니까 ?gdb
(중요한 경우에는 Ubuntu가 설치된 ARM 시스템에서 LLVM/clang 3.5를 사용하여 컴파일되었습니다)
답변1
이는 gcc 최적화 및 후속 문제일 가능성이 높습니다.라인 번호 테이블만든 사람난쟁이 그 지도
프로그램 실행 코드의 메모리 주소와 이 주소에 해당하는 소스 코드 라인을 포함합니다.
(8페이지)
가장 간단한 해결책은 다음을 사용하는 것입니다.스테피함수에 도달하면
~에서GDB 사용자 매뉴얼(65페이지)
단계
제어가 다른 소스 코드 라인에 도달할 때까지 프로그램을 계속 실행한 다음 프로그램을 중지하고 제어를 gdb로 반환합니다.
....
단계 명령은 소스 코드 줄의 첫 번째 명령에서만 중지됩니다. 이렇게 하면 스위치 문, for 루프 등에서 발생할 수 있는 다중 중지가 방지됩니다. 디버그 정보가 있는 함수가 인라인으로 호출되면 단계가 계속 중지됩니다. 즉, step은 해당 라인 내에서 호출되는 모든 함수로 들어갑니다.
또한 단계 명령은 행 번호 정보가 있는 경우에만 함수를 입력합니다. 그렇지 않으면 다음 명령처럼 동작합니다. 이는 MIPS 시스템에서 cc -gl을 사용할 때 문제를 방지합니다. 이전에는 루틴에 대한 디버깅 정보가 있는 경우 서브루틴으로의 한 단계씩 실행이 수행되었습니다.