Пишу проект на 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. Это становится ещё интереснее, если учесть, что прерывание экрана (через прерывание ДПМИ) вызывает вполне успешно другая функция.

Короче, сдаётся мне, линкер как-то голимо линкует все мои объектные файлы. Вероятность косяка с моей стороны практически нулевая, ибо до разделения сорца всё работало на славу. Да и как это так надо накосячить, чтобы аж линкер вылетал по исключению?

Короче, народ, посоветуйте как быть: или отказаться от идеи структурирования, или заменить ассемблер/компилятор/линкер, или сразу уйти в запой/закур на пару недель.

amigo
Приветствую!!!
Да правда не пользуюсь я ТАСМОМ и ФАСМОМ и тем более ваткомовским С++
Однако таком глюки мне что-то оченьзнакомы и что самое интересное на линкёре макрососа. Ну свою проблему я решил тривиально (у меня линкёр был нижней версии, чем файлы PDB и так далее)

Да, дело в линкерё видимо. (иногда я думаю, а чем бумаю эти програмеры!!!! ББЛИНН день матушка налицо.)
Я могу только предположить, что FASM как то по особому гнерирует obj файлы, как то правильно. но так что разработчики ватком этого не ожидали :))

Если твои файлы в формате COFF возми линкёр от майкросовта, попробуй.
Теоретически всё обязано быть ОК!!!
Но ты и сам понимаешь :)

Спасибо. Но делает ли линкер от МС ехешники под защищённый режим ДОС (ДПМИ)? Мне собственно это и нужно. DOS4G он-то явно лепить не умеет... А может, есть какой другой линкер, который DOS4G умеет делать, не знает ли кто? Очень уж мне этаи строчки нравятся, ещё со времён Дума:

DOS/4GW Protected Mode Run-time Version 1.95
Copyright (c) Rational Systems, Inc. 1990-1993

А ещё я думаю попробовать обработать аутпут фасма тулзой coff2omf, про которую узнал где-то на этом же форуме, но у меня ее нема. Может, скинет кто на мыло? Ежели есть возможность, кидайте: dog@front.ru

Ок, пробема решена. Как всегда в подобных случаях пришлось применить радикальную хирургию - ампутацию и протезирование. Вооружился SoftIce'ом, переписал оба ассемблерных модуля заново, для линковки использовал новый wlink из пакета Openwatcom. Попутно поправил один малюсенький незаметный косячок, который и приводил к ошибке в программе, а совместно с глюком wlink'а вообще вводил в заблуждение. Короче, фишка в том что никаких объявлений section 'text' code & section 'data' data нафиг не надо для плоской модели.