FASM + Watcom C = непонятные ошибки при линковке
Пишу проект на Watcom C 10.0 и FASM 1.45 (раньше был tasm, но потребовалась поддержка mmx). Для линковки используется WLINK версии 11.0, ибо 10.0 не поддерживает объектные файлы в формате COFF, генерируемые FASM'ом.
Первоначально проект состоял из 1 сорца на асме и 2х на Цэ и всё компилилось и линковалось на ура. Потом я решил проект немного структурировать и поделить ассемблерный сорц на две логические части. Вот тут-то и пошла по кочкам. Потребовалось переделать все исходники и написать ещё один .h
Но это фигня. Когда всё было перекроено, я попытался это откомпилить+отлинковать и ужаснулся. WLINK вылетел по General protection fault (0Dh). Интересно, подумалось мне, чего же такого я умудрился туда внедрить, что аж линкер заглючило. Начал искать косяки. После пары часов конкретной бани линкер удалось успокоить закомментированием описания секции данных в одном из ассемблерных исходников:
source1.asm:
format coff
section 'text' code
. . . .
pop edi
pop esi
ret
; section 'data' data
extrn xxx
public yyy
public zzz
. . . .
Та же самая операция с другим асм. сорцом результатов не дала - линкер опять начал глюкавить. Но это тоже фигня - слинкованная программа вылетела по тому же исключению, что и линкер до этого. Вообще для flat модели значения cs, es, ds, ss должны быть равны, а тут посмертный дамп программы говорит обратное:
DOS/4GW error (2001): exception 0Dh (general protection fault) at 21F:832BD09C
TSF32: prev_tsf32 5110
SS 227 DS 27F ES 227 FS 0 GS 87
EAX 27F EBX C0010 ECX E0 EDX 27F
ESI 20 EDI 832BD4A7 EBP 8336E700 ESP 8336E6F0
CS:IP 21F:832BD09C ID 0D COD 0 FLG 10246
CS= 21F, USE32, page granular, limit FFFFFFFF, base 0, acc CFFB
SS= 227, USE32, page granular, limit FFFFFFFF, base 0, acc CFF3
DS= 27F, USE16, byte granular, limit 1F, base B190, acc F3
ES= 227, USE32, page granular, limit FFFFFFFF, base 0, acc
Исследования показали, что приведённый выше скриншот вылазит при вызове посредством int 31h (DPMI) прерывания экрана 10h. Это становится ещё интереснее, если учесть, что прерывание экрана (через прерывание ДПМИ) вызывает вполне успешно другая функция.
Короче, сдаётся мне, линкер как-то голимо линкует все мои объектные файлы. Вероятность косяка с моей стороны практически нулевая, ибо до разделения сорца всё работало на славу. Да и как это так надо накосячить, чтобы аж линкер вылетал по исключению?
Короче, народ, посоветуйте как быть: или отказаться от идеи структурирования, или заменить ассемблер/компилятор/линкер, или сразу уйти в запой/закур на пару недель.
Первоначально проект состоял из 1 сорца на асме и 2х на Цэ и всё компилилось и линковалось на ура. Потом я решил проект немного структурировать и поделить ассемблерный сорц на две логические части. Вот тут-то и пошла по кочкам. Потребовалось переделать все исходники и написать ещё один .h
Но это фигня. Когда всё было перекроено, я попытался это откомпилить+отлинковать и ужаснулся. WLINK вылетел по General protection fault (0Dh). Интересно, подумалось мне, чего же такого я умудрился туда внедрить, что аж линкер заглючило. Начал искать косяки. После пары часов конкретной бани линкер удалось успокоить закомментированием описания секции данных в одном из ассемблерных исходников:
source1.asm:
format coff
section 'text' code
. . . .
pop edi
pop esi
ret
; section 'data' data
extrn xxx
public yyy
public zzz
. . . .
Та же самая операция с другим асм. сорцом результатов не дала - линкер опять начал глюкавить. Но это тоже фигня - слинкованная программа вылетела по тому же исключению, что и линкер до этого. Вообще для flat модели значения cs, es, ds, ss должны быть равны, а тут посмертный дамп программы говорит обратное:
DOS/4GW error (2001): exception 0Dh (general protection fault) at 21F:832BD09C
TSF32: prev_tsf32 5110
SS 227 DS 27F ES 227 FS 0 GS 87
EAX 27F EBX C0010 ECX E0 EDX 27F
ESI 20 EDI 832BD4A7 EBP 8336E700 ESP 8336E6F0
CS:IP 21F:832BD09C ID 0D COD 0 FLG 10246
CS= 21F, USE32, page granular, limit FFFFFFFF, base 0, acc CFFB
SS= 227, USE32, page granular, limit FFFFFFFF, base 0, acc CFF3
DS= 27F, USE16, byte granular, limit 1F, base B190, acc F3
ES= 227, USE32, page granular, limit FFFFFFFF, base 0, acc
Исследования показали, что приведённый выше скриншот вылазит при вызове посредством int 31h (DPMI) прерывания экрана 10h. Это становится ещё интереснее, если учесть, что прерывание экрана (через прерывание ДПМИ) вызывает вполне успешно другая функция.
Короче, сдаётся мне, линкер как-то голимо линкует все мои объектные файлы. Вероятность косяка с моей стороны практически нулевая, ибо до разделения сорца всё работало на славу. Да и как это так надо накосячить, чтобы аж линкер вылетал по исключению?
Короче, народ, посоветуйте как быть: или отказаться от идеи структурирования, или заменить ассемблер/компилятор/линкер, или сразу уйти в запой/закур на пару недель.