64비트 어셈에서 스택 사용시 주의사항

엔진과 기타 몇몇 컴포넌트에서 DPC(함수호출에 대한 내용을 일단 저장해두고 나중에 함수 호출)가 필요했기 때문에 꽤 오래전에 DPC 코드를 작성해서  공용 라이브러리 DLL에 넣어놨었다.

DPC(Deffrred Procedure Call)를 구현하기 위해서는 가변인자처리를 해야했고, 따라서 어셈블리코드를 반드시 써야만했다.

x64랑 x86이랑 calling convention이 달랐으므로 파라미터를 넘기는 부분에서 꽤 애먹었었다.

여튼 코드를 작성해서 지금까지 잘 사용하고 있었다(그렇다고 믿었다.)

몇일전에 그 DPC를 통해서 호출한 함수에서 OutputDebugString()함수가 오작동하는 것을 알게 됐다. 정확히는 First-Chance Exception, 대충 win32 함수 안에서 뭔가 문제가 생긴건 알겠는데…

이것만 가지곤 알수가 없잖아.

테스트 결과 OutputDebugString()뿐만 아니라 , 몇 개의 win32 api가 오작동하는 것을 발견했다. 그러니까 DPC를 통해서 호출될때에 한해서다.

눈을 부릅뜨고 더 테스트를 해보고 파라미터를 4개 이하로 넘길때는 win32함수들도 정상 작동하는 것을 알게 됐다.

파라미터가 4개 이하인 경우에는 rcx,rdx,r8,r9레지스터를 통해서 파라미터를 전달한다. 즉 리턴 어드레스를 적어넣는것 말고는 스택을 사용하지 않는다.

그렇다면?

문득 떠오르는게 있어서 문서를 열나게 뒤졌다.

msdn의 x64컨버젼 부분에서 스택은 16바이트 얼라인으로 간주한다는 내용 발견. 이런 쯧.

dpc를 통해서 함수를 호출할때 5개째의 파라미터 부터는 스택을 통해서 전달한다. 이때 파라미터 개수*8로 계산해서 스택 포인터를 뺐는데, 이렇게 되니 16바이트 얼라인 규칙이 무너진것이다.

일부 win32 api를 추적해보니 xmm레지스터도 사용하는 것을 확인했다.

xmm레지스터까지 사용한다면 속도를 위해서 16바이트 얼라인을 사용하는 것이 말이 된다.

16바이트 얼라인 되지 않은 메모리를 movaps등의 명령어로 억세스 하면 크래쉬 해버리니까.

여튼, 파라미터를 전달할때 스택 포인터를 16바이트 얼라인 시키는 코드를 추가했다.

과연…

잘 돌아간다.

코드 짜는데는 5분도 안걸렸는데 원인을 발견하는데까지는 반나절이 걸렸다.

반나절 고민 끝에 버그를 해결했으므로 깨달음을 얻었다. 렙업!

아아 프로그래밍의 세계는 역시 심오해.


답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

%s에 연결하는 중