실행 파일을 디버깅해야합니다. 내 소스 파일의 1653 줄에 중단 점을 넣었습니다. 1653 ~ 1658 행에는 몇 가지 선언이 있습니다. 이제 프로그램을 실행하기 시작했습니다. 1653 번 라인에서 브레이크가 걸리지 않습니다. 대신 1659 번 라인에서 발생합니다. 몇 가지 이유와 해결 방법을 알려주십시오. 사전에중단은 gdb로 exucatble을 실행하는 중 브레이크 포인트를 사용할 때 발생합니다.
덕분에 .....
귀하의 코드는 아마도 디버깅을 위해 만들어진되지 않습니다. 최적화가 설정된 상태에서 컴파일되면 소스 코드 행이 더 이상 생성 된 코드의 어떤 것과도 일치하지 않을 수도 있습니다.
최적화없이 가능한 한 많은 디버깅 정보를 사용하여 빌드하십시오. 이렇게하는 방법은 컴파일러에 따라 다릅니다.
실행 파일을 다시 컴파일 할 수 없다면 갖고있는 것과 함께해야합니다.
unwind은 프로그램이 최적화를 통해 작성 되었기 때문에 발생할 수 있지만 최적화되지 않은 빌드에서도 발생할 수 있다고 제안합니다. 컴파일러는 라인 테이블을 디버그 정보에 포함하고 있으며 라인 테이블은 디버거에 어떤 소스 라인이 생성되어 코드가 생성되었는지 알려줍니다. 예를 들어
15 puts ("This probably resulted in some code being generated.");
16
17 const int arrsize = 32; // code generated? Maybe, maybe not at -O0.
18 char buf[arrsize]; // code generated? Unlikely.
19
20 // Now we'll start our real work...
21
22 puts ("This probably resulted in some code being generated.");
줄 15 또는 22의 중단 점이 예상 한대로 작동합니다. 그러나 16 ~ 21 행에서 코드 생성이 전혀 발생하지 않았기 때문에 디버거에 관한 한이 행은 존재하지 않습니다. 18 번 줄에 중단 점을 입력하면 디버거는 18 번 이후에 생성 된 코드가있는 다음 소스 행을 찾아 중단 점을 배치합니다. 언 와인드 말한다
,이 문제는 (같이 보일지도 소스 라인이 확실하게 될 것 즉시 소스 줄은 예상하지 않은 방식으로 재 배열하거나 아예 생략 할 수 있기 때문에 최적화는 컴파일러에 의해 관여 극적으로 악화된다 일부 코드 생성 중 ..). 최적화 된 코드를 디버그하는 가장 좋은 방법은 혼합 소스 & 어셈블리 디스플레이를 사용하고 프로그램 IMO를 단계별로 따라갈 수있는 충분한 어셈블리 언어를 알고있는 것입니다.
컴파일을 최적화 했습니까? – alk