OberonCore

Могу преположить, что Ваши DLL (и мои тоже) теперь всегда будут на всякий случай ( ) импортировать дополнительные библиотеки. В пользу этой версии говорит и одинаковый прирост в 23КБ. Точно можно выяснить, если прогнать dll-ку через какой-нибудь PE-explorer. Особый интерес здесь представляют секции импорта и экспорта. Думаю, что различия в размере PE-файла из-за них.

Я подозреваю, что в основном включение XDS-C и TSCP сыграло роль в распухании базы. ООП такое ООП.

Насчёт bugs fixed у меня есть подтверждения, я готовлю материал на эту тему. Например, больше не воспроизводится "type guard bug" - это когда при применении охраны типа к результату функции эта функция вызывалась дважды. Теперь на моём тестовом примере этого не происходит.

Если вернуть старый libxds.lib, то линкер ругается вот как:Суффикс "C" подсказывает мне, что речь идёт о функциях, доставшихся нам вместе с XDS-C. Раньше ведь они назывались просто X2C_TRAP_INDEX, X2C_TRAP_NIL и X2C_ASSERT_F соответственно. В новой версии libxds.lib есть и старые имена функций, и новые. Неудивительно, что сам этот файл распух с 314 Кб до 746 Кб!

Интересно, есть ли какая-то опция, чтобы использовать старые функции (раз уж они по-прежнему есть в наличии)? Может быть, удастся вернуть размер dll-ок на прежний уровень. В diff'ах документации я видел, что появилось несколько новых опций компилятора.

Это хорошие новости
Что касается разбухания PE-файлов, то можно попробовать использовать старую версию компоновщика. Прям сейчас этим и займусь.

В примерах появился интересный проект samples/mixed, который, как будто, демонстрирует проект, написанный совместно на Modula-2 и C. Или там два проекта, использующие общую часть исходников? я ещё не разбирался. В общем, добавление XDS-C может облегчить взаимодействие с сишными программами, что может быть весьма актуально. Надо посмотреть.

Обязательно напишите о результатах!

Со старой версией компоновщика (v2.6) прирост составил 107КБ против 111КБ с новым компоновщиком (v2.13.3). Ну, то есть сам компоновщик не слишком-то "виноват".

Старый компоновщик ничего не знает про новые библиотечные расширения. Значит "зараза" прёт из объектных файлов.

Я так понимаю, что это ведь компилятор генерирует обращения к функциям типа X2C_ASSERT_FC при генерации кода стандартной функции ASSERT. И эти имена (их вызовы) зашивает в объектные файлы. Значит, надо копаться в настройках компиляции.

На всякий случай прогнал свой икзешничег через утилиту dumpbin.exe с ключами /imports и /exports. Никакого криминала не обнаружил. Экспорт, как и следовало ожидать, вообще пустой. А импорт только из KERNEL32.DLL и USER32.DLL. Ничего "левого".

Внутри компилятора строка "X2C_TRAP_NIL" без суффикса тоже не встречается, так что вряд ли есть такая опция компиляции.

Хекс-редактором поправил obj-файлы после компиляции: убрал суффиксы "C", поправил длины строк, добавил нулей для компенсации смещения, после чего скомпилировал WebEdit.dll новым компилятором/линкером XDS 2.60. Размер dll-файла после компиляции в XDS 2.51: 59'392; в XDS 2.60 с использованием старого libxds.lib (от 2.51) размер: 61'952, при использовании нового libxds.lib пропатченные объектники всё равно дают больший размер: 72'704.

Вывод: имя функции, с префиксом оно или без, роли не играет. Просто в новой либе больше кода под эти рантаймовые функции.

Дублирование имён внутри libxds.lib, скорее всего, сделано для совместимости с предыдущей версией.

Опробовал новый XDS на своих расчётах.

У меня 2 основных режима компиляции: проверочный (со всеми проверками без оптимизации) и рабочий (без проверок с оптимизацией). В проверочном режиме всё работает как и раньше. А вот в рабочем режиме почти сразу появляется floating overflow. Так что, кажется, в целом надёжность компилятора не слишком увеличилась

Я уже сталкивался с похожими floating overflow'ами в рабочем режиме (в проверочном они у меня не воспроизводятся) в версии 2.50 - они устраняются только танцами с бубном, если, конечно, не хочется считать в проверочном режиме (это в 1.5 раза медленнее).

А есть тестовый проект, на котором бы воспроизводилась ошибка?

Отчёт dumpbin.exe для проекта, собранного в XDS v2.51:
Аналогичный отчёт для того же проекта, собранного в XDS v2.60:

Как видно из отчётов, увеличилась секция инициализированных данных (.data), секция перемещаемых данных (.reloc) и собственно секция кода (.text). Размер секции отладки (.debug) и импорта из внешних библиотек (.idata) не изменился (по крайней мере в памяти, в файле мог и измениться). Секцию неинициализированных данных (.bss) в расчёт можно не принимать, так как её размер в файле всегда равен нулю.

По большому счёту я готов мириться с этим увеличением размера файла. А вот то обстоятельство, что исправлены ошибки, для меня важнее
Осталось разобраться что там с floating overflow.

Пожалуйста, попробуйте разобраться.

Во вложении моя (чуть модифицированная) программа.
На входе принимает файл V.txt - уже лежит в каталоге EXE,
куда программа будет компилироваться. Про режимы компиляции
Debug и Run читайте комментарии в проектном файле.

В режиме Run в XDS 2.51 всё работает, в XDS 2.60 beta почти сразу
вылетает real overflow, он не воспроизводится в режиме Debug.

При подготовке этого сообщения нашёлся ещё один "бубнотанцевый" баг:
если в файле Flow\fDynamicParticle.ob2 закомментировать строчки No. 50 или 57 (там стоят никчёмные, ничего не значащие операторы), то в режиме Run программа вылетает с сообщением invalid location. Это, опять-таки, не воспроизводится в отладочном режиме. Этот баг присутствует как в старой, так и в новой версиях XDS.

Ну как жить с такими багами ?

С уважением,
GH.

Подобные ошибки кодогенератора встречались и мне, да только всё не удавалось создать минимальный проект для их воспроизведения. Решались они иной раз изменением текстовой константы в соседней строке. : )

Что там с real overflow я не знаю, а вот до invalid location я докопался с помощью IDA Pro и XD. Дело в том, что там генерируется PUSH, после чего из стека достаётся сохранённое значение указателя. Вот так это выглядит:Команды PUSH - это уже задвигаются в стек параметры для следующего вызова Space.NewFloatArray. По адресу [esp+1Ch] находится значение указателя f, полученного ранее в результате выполнения NEW. Да только вот незачада: смещение 1Ch было бы правильным, если бы не был сделан перед этим "push 0". После выполнения push значение регистра ESP изменилось, и теперь правильное смещение = 20h. Соответственно, из стека достаётся не запомненное значение указателя, а какое-то постороннее значение (в данном случае = 1), что и приводит к ошибке доступа к памяти, аналогичной разыменованию нулевого указателя.

Если пропатчить exe-файл, заменив смещение 1Ch на 20h, то программа работает нормально и завершается в совершенно другом месте с real overflow, как от неё и ожидается : )

Вот знаю я это всё. И что мне теперь со всем этим делать? : )

По поводу real overflow могу сказать, что это исключение возникает скорее всего в результате выполнения инструкции fscale. Но в каком месте исходников - не знаю.

Вроде, не все модули представлены:
IMHO, начинать нужно с выделения минимального тестового проекта, на котором воспроизводится ошибка. Лучше Вас это никто не сделает.

Респект и уважуха! . А XD что за инструмент, HxD что ли?

А вот это "mailto:support@excelsior-usa.com" не помогает решить проблему?

Processes - стандартный модуль XDS'а. Странно что его у Вас нет...