yuchi's Development Home
글 수 201
현재 엔진 코드에 ml64용 64비트 어셈블리 코드가 적지않게 존재한다.
일단 콜스택 정보가 나오지 않는 것은 rsp레지스터의 값을 함수 안에서 변경하기 때문이다.
함수에 최초 진입했을 당시 rsp레지스터가 가리키고 있는 메모리에 리턴 어드레스가 들어있는데 디버거는 이를근거로 근거로 콜스택을 추적한다. c++코드를 디스어셈블 해보면 rsp레지스터의 리턴어드레스를 유지하기 위한 별도의 코드는 보이지 않는다. 따라서 pdb에 rsp사용에 대한 내용까지 기록되어있다고 판단한다.
어쨌거나 엔진에서 사용하는 상당수의 수학함수들은 x64어셈블리로 작성되어있으므로 이 안에서 크래시하게 되면 콜스택이 제대로 표시되지 않는다.
수학함수 안에서의 크래시는 99% 잘못된 어드레스를 전달했기 때문인데 콜스택 정보만있으면 금방 버그를 잡을 수 있다.
가변인자 함수를 호출할때 말고는 중간에 rsp레지스터를 조작하는 일은 거의 없다. 함수 도입부에 조작하는 경우가 대부분이다. 따라서 함수 진입시의 rsp레지스터로 복원만 시켜주면 콜스택을 확인할 수 있다.
우선 크래시한 화면이다. 매트릭스곱셈 함수인데 인자로 받은 mat2포인터가 잘못되었다.
코드를 보면 레지스터 백업을 위해 32바이트만큼 스택공간을 확보한다. rsp레지스터를 함수 진입시의 값으로 복원하면 콜스택을 확인할 수 있을것이다. 워치창에서 rsp레지스터에 32를 더한다.
콜스택이 제대로 나오는 것을 확인할 수 있다. 이와 유사하게 스택포인터 레지스터 조작으로 콜스택이 확인되지 않는 경우라면 코드 내용을 보고 rsp(32비트라면 esp)레지스터의 내용을 복원해서 콜 스택을 확인할 수 있다.
일단 콜스택 정보가 나오지 않는 것은 rsp레지스터의 값을 함수 안에서 변경하기 때문이다.
함수에 최초 진입했을 당시 rsp레지스터가 가리키고 있는 메모리에 리턴 어드레스가 들어있는데 디버거는 이를근거로 근거로 콜스택을 추적한다. c++코드를 디스어셈블 해보면 rsp레지스터의 리턴어드레스를 유지하기 위한 별도의 코드는 보이지 않는다. 따라서 pdb에 rsp사용에 대한 내용까지 기록되어있다고 판단한다.
어쨌거나 엔진에서 사용하는 상당수의 수학함수들은 x64어셈블리로 작성되어있으므로 이 안에서 크래시하게 되면 콜스택이 제대로 표시되지 않는다.
수학함수 안에서의 크래시는 99% 잘못된 어드레스를 전달했기 때문인데 콜스택 정보만있으면 금방 버그를 잡을 수 있다.
가변인자 함수를 호출할때 말고는 중간에 rsp레지스터를 조작하는 일은 거의 없다. 함수 도입부에 조작하는 경우가 대부분이다. 따라서 함수 진입시의 rsp레지스터로 복원만 시켜주면 콜스택을 확인할 수 있다.
우선 크래시한 화면이다. 매트릭스곱셈 함수인데 인자로 받은 mat2포인터가 잘못되었다.
코드를 보면 레지스터 백업을 위해 32바이트만큼 스택공간을 확보한다. rsp레지스터를 함수 진입시의 값으로 복원하면 콜스택을 확인할 수 있을것이다. 워치창에서 rsp레지스터에 32를 더한다.
콜스택이 제대로 나오는 것을 확인할 수 있다. 이와 유사하게 스택포인터 레지스터 조작으로 콜스택이 확인되지 않는 경우라면 코드 내용을 보고 rsp(32비트라면 esp)레지스터의 내용을 복원해서 콜 스택을 확인할 수 있다.
