Ru-Board.club
← Вернуться в раздел «Прикладное программирование»

» Чудовищный баг DCC

Автор: FalseMaster
Дата сообщения: 04.08.2016 01:11
Вкратце обрисую сложившуюся ситуацию. Сижу я, значит, кодю помаленьку, периодически компиляю накоденное. И вот в один прекрасный момент получаю вылет по AV. Поскольку был почти уверен в отсутствии ошибки, сразу полез в дебаггер. Открываю прогу в "Оле"… и ужасаюсь – эмбаркадеровское поделие сгенерило короткий переход назад вместо ближнего вперёд (самка собаки, а ведь они ещё и бабосы за свой высер хочут). Небольшая рокировка кусочков кода временно решила проблему, а затем код разросся, дистанция прыжка увеличилась и проблема рассосалась сама собой. НО на хвосте я вертел такое программирование, когда после каждого чиха приходится открывать прогу в дизасме и проверять правильность переходов. После того, как докатал прожку, решил искусственно (NOP'ами) смоделировать описанный конфуз в тестовом проектике. Не сразу, но получилось. На всякий случай компильнул тот же код TAsm'ом – всё пучком. В общем просьба моя заключается в том, чтобы сидящие на Делфях версий выше XE, скомпилили тестовый проект (бинари присутствуют, дабы не думал честной народ, что ТС гонит), и проверили на предмет вышеописанной бессовестной подлянки от сурьёзной конторы. Задача состоит в том, чтобы найти минимальную (начиная с XE2) версию DCC без этого бага (если конечно он вообще был исправлен).
Автор: Dronton2
Дата сообщения: 04.08.2016 12:10
Скомпилировал на ХЕ3. Дизассемблировал. Джампы правильные.
Только DLL получился размером в 21КБ.
Автор: FalseMaster
Дата сообщения: 04.08.2016 16:45
Dronton2

>> Скомпилировал на ХЕ3. Дизассемблировал. Джампы правильные.
Премного благодарен, остальное в личке.

>> Только DLL получился размером в 21КБ.
Я намеренно либы нерабочие сделал, чтобы избежать обвинений в распространении малвари, к тому же у меня системные юниты полностью вычищены.
Автор: asutp2
Дата сообщения: 04.08.2016 17:31
FalseMaster, а ты кодишь также, как пишешь свои сообщения?

По сути вопроса - если считаешь, что нашел баг в компиляторе, то сообщи о нем в Эмбу (с приложением подтверждающих исходников)
Автор: FalseMaster
Дата сообщения: 04.08.2016 19:55
>> а ты кодишь также, как пишешь свои сообщения?

Ещё хардкорнее А если серьёзно, я просто сильно расстроился из-за произошедшего и не справился с эмоциями.

>> если считаешь, что нашел баг в компиляторе, то сообщи о нем в Эмбу

Дык поздняк метаться уже, ошибка исправлена, и это не может не радовать.
Автор: FalseMaster
Дата сообщения: 17.08.2016 02:57
Рановато я обрадовался. Не, баг действительно исправлен, но какой ценой. Видать в Эмбе решили не заморачиваться по таким "пустякам" и тупо отключили оптимизацию при формировании команд переходов. Теперь если прыжок идёт вперёд (на ещё не скомпилированный код) и при этом пересекает выровненный (директивой .ALIGN) участок, компиль без лишних раздумий лепит ближний переход. Таким образом мы получаем инструкции длиной 5/6 байт вместо 2. В общем кодогенерация стала хуже, чем у древнего TAsm'а, такие дела.
Автор: Dronton2
Дата сообщения: 17.08.2016 19:14
Теперь понятно, почему размер скомпилированного кода в новых версиях увеличился.
FalseMaster, это на какой версии дельфей, на последней?
Автор: FalseMaster
Дата сообщения: 21.08.2016 04:54
>> Теперь понятно, почему размер скомпилированного кода в новых версиях увеличился.

Думаю, что на раздутие бинарников длина джампов влияет в последнюю очередь. С каждым релизом горячие пиндосские парни наворачивают всё больше и больше говнокода в VCL/RTL. К слову, если ранее достаточно было просто почистить System.pas/SysInit.pas и не задействовать ООПщину, то теперь дело усложнилось тем, что даже обычные (не методы) процедуры/функции требуют наличия класса RefAttribute (потомка TCustomAttribute, а следовательно и TObject). Пришлось снова натравить на детище Эмбы всех своих злых собак (отладчик, дизасм, hex-редактор)

>> это на какой версии дельфей, на последней?

На той, которую я у тебя выпросил (XE3): внутренняя версия компилятора – 24.0, версия файла – 17.0.4770.56661. За другие поручиться не рискну. Если имеешь возможность проверить, было бы очень любопытно ознакомиться с результатами сего исследования.
Автор: asutp2
Дата сообщения: 21.08.2016 05:57
FalseMaster, а ты уверен, что в Питерском центре Эмбы работают "горячие пиндосские парни" ? ))))
Автор: FalseMaster
Дата сообщения: 21.08.2016 23:34
>> а ты уверен, что в Питерском центре…

В питерском офисе/представительстве "куют железо" местные торгаши, а вся разработка ведётся за бугром.
Автор: Dronton2
Дата сообщения: 22.08.2016 00:33
XE3 - версия достаточно древняя. Вдруг (внезапно) в более поздних версиях они поправили джампы. Проверить, к сожалению, не могу.
Если так критичен размер выходного файла, попробуй KOL , Lazarus и FPC
Автор: FalseMaster
Дата сообщения: 22.08.2016 05:49
>> Проверить, к сожалению, не могу.

Это печально.

>> Если так критичен размер выходного файла…

1536 байт простейший HelloWorld, куда уж меньше-то? Не, ну можно конечно, только с нарушением спецификации на PE от мелкософта, но я не сторонник таких извратов.
Автор: asutp2
Дата сообщения: 22.08.2016 08:09
FalseMaster, а расскажи, когда именно из питерского офиса выпнули разработчиков? Я вот не в курсе, честно

По ситуации с размером генерируемого кода - вот скажи мне, ЧТО изменится, если HelloWord будет 100 байт, а не 1536? Или возьмем реальный проект - что изменится для пользователей или компьютеров производства 2005+ года, если скомпилированный код будет 5-10 Мб, а не 40? НИЧЕГО. Я знаю всего единственную проблему - если для ежедневного обновления бинарников используется медленный gprs или диалап на 56 кбит/с без использования инкрементальных патчей.

Ради интереса открыл папку с установленным офисом 2007, только корневая папка софта от MS содержит exe и dll на 185 876 232 байта. И всё работает шустро.
Автор: FalseMaster
Дата сообщения: 22.08.2016 23:19
>> расскажи, когда именно из питерского офиса выпнули разработчиков?

Увы, но сие невозможно, ибо я не умею переключаться на альтернативные реальности зеленоватых анонов из тырнета.

>> что изменится для пользователей или компьютеров производства 2005+ года, если скомпилированный код будет 5-10 Мб, а не 40? НИЧЕГО.

А теперь посмотрим на этот вопрос глазами девелопера или крякера. Элементарное математическое действие показывает нам, что в 8-4 раза возрастает вероятность появления ошибки при использовании сторонних юнитов/объектников, во столько же раз увеличивается сложность разбора кода (большая часть которого – ненужный шлак) в сорцах/отладчике, алсо время дизассемблирования и поиска в листинге при ковырянии в чужой проге. Это раз. Юзер под ником Dronton2 накидал способов уменьшения размера выходных бинарей, я в свою очередь дал понять, что для меня эта тема уже неактуальна. Вопрос: какова цель твоего несостоятельного, алогичного и оффтопного заявления? Это два.

>> Ради интереса открыл папку с установленным офисом 2007

А теперь сделай его портабельным без всяких виртуализационных решений а-ля Thinstall (ручным патчингом). Пообмазывайся недельку "матрицей" до блевоты, потом отпишешься, со сколькими тёлками в красных платьишках удалось замутить.
Автор: asutp2
Дата сообщения: 23.08.2016 08:29
FalseMaster, ты скажи, чего такое забористое куришь? )))))))))
Автор: FalseMaster
Дата сообщения: 23.08.2016 20:30
>> ты скажи, чего такое забористое куришь?

Да какое там забористое. В сравнении с твоим термоядерным составом моя формула – так, баловство.

Страницы: 1

Предыдущая тема: добавить watermark в файл pdf


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.