LINUX.ORG.RU
ФорумTalks

зависимость выдаваемого асм-кода от нефункциональных вставок

 , , ,


0

4

Извиняюсь за оффтоп, речь про компилятор ms vc 5 (вроде, 97 года).

Если в большой программе где-то в начале вставить бесполезное typedef int random_string_5423432; или int func_name_35432423(void); (в том числе не задевая номера строк), то у него (иногда, но всегда репродуцируемо) меняется ассемблерный дамп получившегося бинарника. Оба варианта (до и после) корректные, отличия касается, например, выбора другого регистра для хранения какого-нить промежуточного числа или другого порядка сложения/вычитания в формуле a[b-c]. Или, например, вместо add eax,[some_mem] оно делает mov ecx,[some_mem] / add eax,ecx или наоборот.

Зависимость наблюдается от количества таких вставок, их содержание не важно. То есть, допустим, нет вставок - один бинарник, 5 typedef-ов - другой, 12 typedef-ов - третий, 3 typedef-а и 2 функции - такой же как 5 typedef-ов. Дублирующие объявления не влияют (т.е. если написать typedef int q1; typedef int q1; то это то же самое как если бы он был один.

Вопрос вобщем-то один - как такое вообще может происходить? Не свидетельство ли это постоянного повреждения памяти, когда код хранилища идентификаторов бьёт память кодогенератору? Или они туда (в генератор асм-инструкций) засунули рандом-генератор, сидированный количеством имеющихся идентификаторов?

Другие версии msvc не проверял. В gcc с таким не встречался вроде (или плохо смотрел).

★★★★★

Последнее исправление: firkax (всего исправлений: 3)
Ответ на: комментарий от cocucka

Сравнивал соседние версии бинарников чтобы проверить что ничего лишнего не задето. Вобщем-то заметил уже давно. По идее должны меняться только таймстампы и те места где был изменён функционал (если изменения мелкие то вполне локализуемо, или тем более если их нет). И не должны отражаться изменения в заголовочных файлах, не касающиеся этого бинарника.

firkax ★★★★★
() автор топика

Да запросто может биться память или неинициализированные переменные. Багов в этих древних компиляторах...

mittorn ★★★★★
()

ms vc 5 (вроде, 97 года)

То есть ещё до мезозоя^W C++98...

Или они туда (в генератор асм-инструкций) засунули рандом-генератор, сидированный количеством имеющихся идентификаторов?

Ну а как ещё GPR распределять-то? )

GAMer ★★★★★
()

Встречный вопрос: компилятор обязан выдавать один и тот же асм на одинаковом коде (учитывая твои вставки)? Фазы луны / общее состояние памяти и состояние системы не влияет?

untitl3d
()
Ответ на: комментарий от cocucka

У меня есть объяснение, но я слишком пьян чтобы его сейчас писать.

Месье Ферма, перелогиньтесь проспитесь

static_lab ★★★★★
()
Последнее исправление: static_lab (всего исправлений: 1)
Ответ на: комментарий от untitl3d

Встречный вопрос: компилятор обязан выдавать один и тот же асм на одинаковом коде (учитывая твои вставки)? Фазы луны / общее состояние памяти и состояние системы не влияет?

Не, в общем случае не обязан. Код аллокации регистров обычно основан на решении задачи раскрашивания графа. Тут у чувака просто граф изменился слегка или ноды в нём в другом порядке вставлены в стек при раскрашивании, и поэтому используются другие регистры.

Про это можно тут почитать: https://groups.seas.harvard.edu/courses/cs153/2018fa/lectures/Lec20-Register-alloc-I.pdf

Но мне тоже интересно, какое это имеет значение в его случае. И зачем ему такой старый компилятор 0__o

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 3)
Ответ на: комментарий от untitl3d

Учитывая, что вставки вообще никак не участвуют, мне казалось что да.

firkax ★★★★★
() автор топика
Ответ на: комментарий от firkax

General Purpose Register, он же регистр общего назначения, он же РОН.

Siborgium ★★★★★
()
Ответ на: комментарий от hateyoufeel

Ну, может быть конечно. Хотя всё равно странно - ведь в раскрашивании только используемые переменные и временные значения должны участвовать. А посторонний typedef, даже будучи занёсён в общую таблицу (хеш-таблицу?) списка доступных идентификаторов, этими алгоритмами должен быть просто пропущен мимо и ни на что не повлиять. Что там надо накрутить было чтоб он влиял?

Но мне тоже интересно, какое это имеет значение в его случае.

Для дополнительного контроля за отсутствием незапланированных изменений (багов) в бинарнике после пересборки. В некоторых случаях иногда.

firkax ★★★★★
() автор топика
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от firkax

должен быть просто пропущен мимо

Хеш-таблица имеет такое свойство, что при вставке элементов порядок уже вставленных может измениться (если произойдёт перехеширование). Да и порядок вставки влияет на порядок итерирования (в случае коллизий).

Так что если в компилятора есть таблица всех идентификаторов и где-то в кодогенераторе происходит итерация по ней (с логикой, что нам не принципиален порядок обработки элементов, поэтому будем их обходить прямо как они лежат в таблице), то даже если мы игнорим новые элементы, мы как минимум можем обойти старые в другом порядке.

KivApple ★★★★★
()
Последнее исправление: KivApple (всего исправлений: 2)

Тебе надо в os2museum написать, они такое любят

luke ★★★★★
()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)