Appler 디버깅하기 ___ 7

이미 수정까지 완료한 사항이지만, 지난 번과는 달리 이번에는 DOSBox를 수정해서 문제를 해결해 보았습니다.

지난 번에 수정을 했던 Ubuntu system의 HDD가 고장이 나서, 다른 HDD에 새로 시스템을 꾸미다 보니 결국은 같은 문제에 봉착하게 되었습니다.
그래서 이번에는 다른 방식으로 문제를 해결해 보고자 하는 생각에...


우선은 문제가 되는 그 화면

문제가 되는 화면, Path가 이상하고 Directory도 이상합니다.

이 문제는 DOS Interrupt 21h, AH=60h일 때의 오작동으로 인한 문제였음은 이미 앞선 포스팅에서 밝힌 바 입니다.

해당 부분을 처리하는 루틴은 dos.cpp의 DOS_21Handler()에 있습니다.

DOS_21Handler()

AH=60h (Canonicalize)가 해당하는 루틴입니다.

디버거를 이용해 trace를 해 본 결과 DOS_canonicalize()라는 함수를 수정하면 될 것으로 보였습니다.

DOS_files.cpp의 DOS_Canonicalize()

마지막에 Backslash만 붙여주면 되는 문제였기에, 문자열의 마지막에 Backslash가 있는지 없는지 검사해서 없을 때에만 붙여 주면 된다 생각했습니다.

그러나 이 루틴에 입력되는 문자열이 디렉토가 아닌 파일인 경우도 있기에, 무조건 Backslash를 넣어 주어서는 안됩니다.

몇번의 디버깅과 고민 끝에 입력 문자열의 마지막에 Backslash가 있다면 디렉토리이므로 이 경우에만 마지막에 Backslash를 검사하고 붙여주도록 수정하였습니다.

다음이 수정한 결과입니다.

위와 같이 수정하였습니다.

수정하고 빌드하여 확인한 결과 화면입니다.

이젠 정상 작동합니다.

Appler 디버깅하기 ___ 6

마지막 포스팅에서 해결할 수 있는 방안은 제시했지만,
- 미해결 상태로 남겨둔 것이 찜찜하기도 했구요,
- 어셈블리 공부도 해야겠다 생각도 했구요,
- 또...Appler를 적극적으로 활용할 필요도 있고 해서 손을 대 보았습니다.

단지
1) 문자열의 마지막에 백슬래쉬가 있는지 여부를 검사하고
2) 없으면 백슬래쉬를 추가해주고
3) 있으면 그냥 놔둔다
는 단순한 루틴인데도 어셈블러로 짤 엄두가 잘 나지 않더군요.

그래서 비교적(?) 무대뽀 정신으로 해결해 보고자, 인터넷을 뒤졌습니다.
문자열 두개를 붙이는 strcat() 같은 어셈블리 소스코드를 찾으면 쉽게 변형해서 적용이 될 거 같았습니다.

http://assembly.happycodings.com/ : 별로 체계는 없지만 간단하고 유용한 샘플코드를 제공합니다.

http://cs.smith.edu/~thiebaut/ArtOfAssembly/artofasm.html : 뭔가 유명할 것 같은 이름이네요. The Art of Assembly Language Programming. PDF 도 존재하고 내용도 매우 충실해 보입니다. 컴퓨터의 구조에 대해서도 좋은 참고 자료가 되겠네요.

마침 두번째 사이트에서 strcat를 포함한 string 함수에 대한 부분이 있었습니다.
http://cs.smith.edu/~thiebaut/ArtOfAssembly/CH15/CH15-5.html#HEADING5-48

그런데 이건 해당 기능을 구현하는 것이 아니라 이용하는 겁니다.
UCR Standard Library라는 것이 존재하는데, 이 Library에 각종 string 함수들도 포함되어 있다고 하더군요.

해서 찾은 것이,
http://net.pku.edu.cn/~course/cs201/2003/mirrorWebster.cs.ucr.edu/Page_asm/ucrlib/stdlibv2.html
여기에 어셈블리 소스 코드도 모두 포함이 되어 있습니다.

strcat.asm이라는 파일이 있어서 찾아 보니,

strcat 프로시져

strcatx 호출하고 끝입니다.
그래서 strcatx 찾아 봤습니다.

strcatx 프로시져

알고 보면 별로 어렵지 않은데, 초짜인 저에겐 그저ㅠㅠ
그래도 어셈블리 명령어 찾아가며 가까스로 이해하고
이 부분을 변형해서 사용하기로 했습니다.
cld : Clear Direction
repne : Repeat while not equal
scasb : scan string(byte)
lodsb : load string(byte)
stosb : store string(byte)
대충 이런 의미들이더군요.
어셈블리 언어가 어려운 이유 가운데 하나가, 저런 명령어들이 묵시적으로 사용하는 레지스터/플래그 등을 기억해야 한다는 점인 거 같습니다.


이젠 DOSBox에서 Appler 소스를 고치겠습니다.
예전에 많이 보았던 DM.ASM의 ReadDirectory 부분을 다음과 같이 고쳤습니다.

DM.ASM

그리고 make

(사실은 이거 성공하기까지 한 5번은 고치고 디버깅하고를 반복했을 겁니다.)

make

Appler 실행하고 F3 눌러서 Disk Manager 실행하면 Path와 Directory 모두 잘 나옵니다.

Appler의 Disk Manager

허접하지만, 위에 소스를 보시면 무작정 마지막에 Backslash를 붙이는 게 아니라
마지막 문자가 Backslash가 아닐 때에만 붙이도록 고쳤습니다.

따라서 나중에 DOSBox가 문제점이 개선되어 나오더라도 Appler의 소스를 다시 건드리지 않아도 정상 작동할거라는 겁니다.^^


나이가 들어서 그런지, 저 짧은 루틴 분석하는 데에도 중간에 졸리고 귀찮고...그렇네요.
역시 프로그램은 만드는 것보다 분석하는 게 더 힘드네요.
그래서인지 다른 사람이 만든 소스를 분석해 보는 정성과 노력을 하는 사람은 틀림없이 성공할 수 있지 않을까 싶습니다.

이 일을 하면서 Appler를 수정했다는 자기 만족 보다는 UCR Standard Library라는 게 있다는 걸 배운 게 더 큰 성과가 아니었나 싶습니다.

Appler 디버깅하기 ___ 5

앞 선 포스팅에서 대략의 결론을 내렸지만,
디버깅을 하는 또 다른 방법이 있기에 번외편으로 간략하게 소개하고자 합니다.

예전에 DOSBox의 내장 디버거에 대한 소개를 한 적이 있습니다.
http://re-coder.blogspot.kr/2013/06/dosbox.html

이 내장 디버거를 사용하여 디버깅을 하는 방법입니다.

먼저 내장 디버거를 사용하는 경우의 장점은,
- 소스가 없어도 됩니다.
- 소스가 있다고 해도 디버그 모드로 다시 빌드할 필요도 없습니다.
- 터보디버거와 같은 별도의 디버거가 필요 없습니다.

반면에 단점은,
- 소스가 있어도 소스레벨 디버깅이나 소스와 연계된 디버깅이 불가능 합니다.
- 내장 디버거의 제한된 기능을 이용해야 하기에 비효율적일 수 있습니다. (아무래도 전문 디버거보다야 기능과 편의성이 떨어집니다.)
- 어셈블리어/로우레벨 디버깅/리버스엔지니어링과 관련된 일정한 수준 이상이 되어야 디버깅이 가능합니다.

저의 경우엔 마지막 조건에 부합하지 못하는 관계로 엄두를 내지는 못 할 상황이지만, 이번 Appler의 경우에만 가까스로 디버깅이 가능했던 듯 합니다.

먼저 내장 디버거가 활성화된 DOSBox를 실행시킵니다.

DOSBox의 실행과 함께 표시된 디버거 화면

이제 디버깅을 하고자 하는 Appler를 실행시킵니다.

Appler 실행

DOSBox 화면에서 Alt-Pause를 누르면 실행이 중단되고 디버거에 입력이 가능하게 됩니다.
앞선 포스팅에서 알아낸 대로, 디버깅을 하기 위해 breakpoint로 지정할 부분이 INT 21 (AH=60h)입니다. 디버거에서 help를 입력하면 내장 디버거에서 사용할 수 있는 키와 명령어가 있습니다. 여기에 있는 대로 "bpint 21 60"을 입력 합니다.

INT 21 (AH=60h)에 대해 Breakpoint를 설정합니다.

"bplist"를 입력하면 breakpoint가 설정이 되었는지 확인이 가능합니다.

breakpoint가 설정되었음을 확인

이제 내장 디버거에서 F5를 눌러서 Appler가 계속 실행을 하도록 해 줍니다.


적당한 시점에 문제가 되는 화면으로 진입하도록 Appler에서 F3 키를 눌러 줍니다.

idle 상태에서 F3을 눌러 Disk Manager로 진입 시도

이제 바로 실행이 멈추고 디버거가 활성화 되었습니다.
실행이 멈춘 곳은 breakpoint로 설정한 int 21 입니다.

INT 21h에서 멈춘 상황

디버거에서 F10(Step Over)로 int 21을 수행 한 후, Alt-D를 눌러 DS:SI의 메모리 내용을 확인해 봅니다. 역시나 마지막에 Backslash가 없음을 알 수 있습니다.

INT 21h을 실행 후 메모리 확인

SM 명령어를 이용하여 마지막에 Backslash(5C)를 넣어 줍니다.

Set Memory로 backslash 추가

마지막에 Backslash가 추가되었음을 확인할 수 있습니다.

메모리 변경 확인

이제 다시 F5를 눌러 실행을 계속 하도록 합니다.
아마 2~3번 정도 같은 부분에서 멈출 것이고, 그 때마다 위의 과정을 반복해야 합니다.
(Step Over, Memory 확인, Memory 수정)

이렇게 하고 나면 정상적인 화면이 나오는 것을 볼 수 있습니다.

정상 화면

만약에 소스를 가진 DOS용 프로그램을 DOSBox의 내장 디버거로 디버깅을 하려면, 소스빌드시에 Map 파일과 Assembly Listing 파일을 만들도록 하면 디버깅에 조금 도움이 되지 않을까 싶습니다.

Appler 디버깅하기 ___ 4

터보디버거가 어째 좀 불안해서 디버깅을 하다가 새로 시작하곤 해야 하는 문제가 있었기에 의욕이 급속히 감소 되었더랬습니다. (지난 포스팅 말미에 썼던 문제점입니다.)

거기에 레퍼런스로 사용하던 Oracle의 VirtualBox도 말썽을 부렸습니다.

4.2.14 버전으로 업데이트하고 나니 키보드도 제대로 작동하지 않는 문제가 발생하더군요.

처음엔 제가 사용하는 리눅스의 사양이 너무 딸려서 시스템의 오작동이 아닌가 생각 했는데, 윈도우즈용도 마찬가지인 것을 확인하고는 참...어이가 없었습니다.

Oracle이 겨우 이런 회사인가....

며칠후에 4.2.16으로 업뎃하고 나니 다행히 정상으로 돌아오긴 했습니다.

암튼 이래저래 시간은 흘러가고 디버깅은 지연되고....하다가 겨우 다시 붙잡았습니다.

첫번째 디버깅 타겟으로 잡은 것은 Path&Filter 부분이었습니다.

Path&Filter 부분에서 Path와 Filter 사이에 backslash가 없었던 문제부터 디버깅을 해 보기로 했습니다.

찾아보니 Path, Filter, PathFilter라는 변수가 있었고, 이 변수를 채우는 프로시져로 ReadDirectory가 있었습니다.

먼저 VirtualBox에서 이 부분을 디버깅하면서 나온 정상적인 결과를 보겠습니다.

int 21h(ah=60h)를 호출한 후

Path 변수를 확인해 보니 문자열의 마지막에 Backslash가 있습니다.

터보디버거에서는 어쩐 일인지 Path 문자열을 Watch에 등록했는데, 앞 두글자만 보여주더군요. 그래서 Data Inspecting으로 주소를 확인하고 View-Dump로 메모리를 확인해 보니 문자열 모두를 볼 수 있었습니다.

VirtualBox에서는 정상으로 작동하고 있었기에 이걸 정상적인 결과로 가정했습니다.

소스에서 보는 DOS interrupt인 int 21h에 대한 자료를 찾아보았습니다.

Ralf Brown이라는 분이 정리한 자료가 있는데, 얼핏 보았는데 상당히 자세한 듯 합니다.

http://www.cs.cmu.edu/~ralf/files.html

우선 2개의 interrupt에 대한 것만 보면,

INT 21h(AH=60h) TRUENAME

INT 21h(AH=1Ah) Set DTA

그러면 같은 부분을 DOSBox에서 실행했을 때는,

DOSBox에서 디버깅한 경우, Backslash 없음.

어느쪽이 맞는건지 모르겠지만 VirtualBox와 DOSBox가 서로 다르게 작동한다는 것은 확실합니다. 그리고 Appler가 실제 MS-DOS를 기반으로 개발된 것을 감안한다면 VirtualBox의 작동방식이 맞다고 보는 것이 타당할 것입니다.

근본적으로 저 문제를 해결하려면 DOSBox를 수정하는 것이 맞을테고, 수정의 용이함이나 Side Effect를 최소화하면서 Appler를 제대로 구동하려면 Appler를 수정하면 될 것입니다.

어셈블리 프로그래밍에 능숙하지 않은 관계로 소스의 수정은 뒤로 미루고,

다음 문제를 디버깅해 보기로 했습니다.

디렉토리 내의 파일이름들 리스팅에도 문제가 있었고, 사실은 이게 제일 큰 문제였습니다.

처음엔 조금 막막했지만, 흔히들 디렉토리 내의 파일 이름들을 얻어 오는 C의 함수로 FindFirst()와 FindNext()를 사용했던 기억이 났습니다.

그리고 소스내에서 동일한 이름의 매크로가 있는 것을 찾아냈습니다.

FindFirst, FindNext 매크로

매크로 무지 간단합니다.

그냥 DOS Interrupt 호출이네요.

아까 보았던 자료에서 위의 Interrupt에 관한 부분을 찾아 보았습니다.

INT 21h(AH=4Eh) FindFirst

INT 21h(AH=4Fh) FindNext

그런데...정말 혹시나 하는 생각이 들었습니다.

앞서 디버깅한 Path&Filter의 문제로 디렉토리의 파일 이름들도 문제가 생긴게 아닐까 하고..

그래서 디버깅 하면서 바로 수정해서 확인 해 보았습니다.

Path의 마지막에 Backslash(5Ch) 넣어주기

Backslash가 들어갔습니다.

Path&Filter 뿐 아니라 Directory 부분도 정상적으로 나옵니다.

Disk Manager 화면으로 진입하면 ReadDirectory라는 프로시져가 2번 호출이 됩니다.

두번 모두 마지막에 Backslash(5Ch)를 넣어주면 모든게 정상이 됩니다.

이젠 DOSBox의 개발진에게 이 문제를 리포트하든지,

내가 직접 DOSBox를 수정하든지, Appler를 수정하든지...하면 되겠네요.

Appler 디버깅하기 ___ 3

이제 빌드가 다 되었으니 디버깅을 하기 전에, 정상적으로 작동을 하는지는 확인해 봐야겠죠?
필요한 파일들(*.rom, *.dsk 등등)을 빌드한 폴더에 복사해 넣고서 확인해 보았습니다.

초기화면

데모화면

로드런너

디스크매니저. 문제도 그대로...

디버거

Appler 디버깅하기 ___ 2

일단 빌드해서 startup.asm은 무사히 넘어갔지만,

다음으로 걸린 부분은 floppy.inc 입니다.

emulate.asm을 컴파일하다가 floppy.inc에서 에러가 났습니다.

에러가 난 부분입니다. 역시 잘 모르겠지만 뭔가 기묘하네요.

CurrentDrive와 OtherDrive를 찾아보니 저렇게 선언되어 있는데 이것도 기묘합니다.OTL

우선은 xchg라는 인스트럭션이 뭔지 몰라서, 다시 터보 어셈블러 퀵 레퍼런스를 참조했습니다.

xchg는 값을 바꿔주는 거군요. 일종의 swap이네요.

그런데 이번에 문제가 되는 부분은 앞서보다 복잡하네요.
CurrentDrive/OtherDrive가 사용되는 곳이 많아서 종잡기도 힘들고,
선언된 곳의 저 모양새는 대체 무엇인지 이해가 되질 않습니다.

Drive_S가 배열인걸까요?
그래서 0번은 CurrentDrive, 1번은 OtherDrive로 사용되는 거...
이건 매뉴얼을 다시 찾아 보기로 하고...

Drive_S라는 걸 찾아보니 일종의 structure로군요.

Globals.inc에 선언되어 있습니다.

위에서 보았던 CurrentDrive와 OtherDrive의 선언 부분의 의미를 알아냈습니다.
CurrentDrive    Drive_S    <0>
Drive_S 타입으로 변수 CurrentDrive를 선언하면서, 초기값 0을 할당한 것입니다.
Drive_S는 스트럭쳐로 여러개의 값을 가져야 하지만 ?로 표시되어 있는 ID에 대한 것만 초기화 해 주는 것인 듯 합니다.

터보 어셈블러의 User's Guide 12장에 있는 해당 부분은 다음과 같습니다.

그런데, 아직도 에러가 난 부분의 의미가 뭔지 모르겠습니다.
CS:OtherDrive[SI-1]-CurrentDrive

각 부분의 의미도 정확히 파악이 되지 않으니 전체가 뭘 의미하는지도 모르겠고,
[]이 배열인 듯 하면서도, 선언된걸로 보면 배열이 아니었고...상상력이 부족한걸까요?

좀 크게 보겠습니다.

DeviceSelect 프로시져

하나의 프로시져 였습니다. DeviceSelect라는...
경우에 따라 DeviceSelect10 혹은 DeviceSelect20을 수행하는데, 문제가 되는 부분은 DeviceSelect10인 경우입니다.

이 프로시져를 호출하는 경우를 좀 봐야겠습니다.

ResetFloppy 프로시져

C0EBr/C0EBw 레이블

아래쪽의 C0EBr/C0EBw는 레이블 이름도 이상하고, 시작이 어디서부터인지도 명확하지도 않고 헷갈립니다.
반면에 위쪽의 ResetFloppy는 뜻이 비교적 명료합니다.

좀 더 자세히 분석해 보기 전에 몇가지 모르는 것들을 찾아보았습니다.

Save/Restore 매크로

자주 나오는 Save/Restore는 매크로였고 간단하게 push, pop으로 구현되어 있습니다.

IRP 지시어

IFNB 지시어

매크로에서 사용된 IRP와 IFNB 지시어에 대한 설명이구요,
IRP로 Repeat를 하는데, 인자들 리스트를 r로 정의하였고 IFNB에서 리스트가 비어있는지 검사하면서 반복하는 듯 합니다.

even 지시어

프로시져의 시작부분에 있던 even이라는 지시어에 대한 설명입니다.
16 bit memory alignment를 위해서 짝수번지에 맞추라는 의미인 듯 합니다.

lods 인스트럭션

메모리에 있는 것을 읽어서 al(혹은ax, eax)에 넣는 작업을 합니다.
REP 혹은 LOOP로 반복구간을 정하나 봅니다.


다시 소스를 확인해 보겠습니다.

호출시 al에 담긴 값이 CurrentDrive의 ID와 일치하면 DeviceSelect20을 수행하고 프로시져를 마칩니다. 즉, 바꿀 필요가 없다는 의미이겠죠.
그렇지 않고 바뀌어야 한다면 WriteTrack을 호출하고 돌아와서 CurrentDrive의 값을 하나씩 읽어와서 OtherDrive에 있는 값과 바꿔치고, OtherDrive의 값을 다시 CurrentDrive에 넣습니다.
여기에서 [SI-1]이 사용된 이유는 그 위에서 lods byte ptr CS:[SI]를 수행하면서 si의 값이 증가되었기 때문인 듯 합니다.
그렇다면 어째서 CS:OtherDrive[SI-1]-CurrentDrive일까요?
CurrentDrive를 왜 뺀걸까요?

사실 모르겠습니다. 그리고 CurrentDrive를 빼지 않는게 맞는 것 같습니다만....
일단 저 부분을 제 생각대로 고치고, 나중에 확인해 보겠습니다.

-CurrentDrive 제거

뜨악...그래도 에러?

대충 메시지 보고 찍어서 다시 수정해 보았습니다.
두번째 에러는 실수로 건드렸나 봅니다.

byte ptr 추가

이제야 빌드 완료입니다.

음...디버깅을 한다고 했는데, 겨우 빌드까지만 다 했습니다.
빌드만 했는데 진이 다 빠진 느낌입니다.
오늘은 여기까지만....