G CC измененная / настраиваемая цель с пользовательским соглашением о вызовах на x86-64

Question

Мне было интересно, можно ли (в разумные сроки) изменить существующую или определить новую цель сборки для g cc. Цель состоит в том, чтобы внести незначительные изменения, такие как изменение регистра, в котором возвращается результат функции, или передача аргументов с использованием регистров, отличных от стандартного ABI SystemV для x86-64.

Например, если я хотите изменить регистр для возвращаемого значения функции с RAX на R8 или вернуть 64-байтовую структуру, используя YMM0 и YMM1, не записывая ее самостоятельно, используя код x86.

(Background) I ' я работаю на небольшой самозаписывающейся ОС, поэтому мне было интересно, можно ли не придерживаться ABI System-V или той, что используется Microsoft для Windows. Совместимость с существующими библиотеками и прочим не является обязательной, поскольку каждая строка кода ОС написана мной. Я использую только g cc, ld и objdump. Нет gdb, et c ...

Если это возможно, где я должен делать такие изменения в исходных или конфигурационных файлах g cc? Я клонировал репозиторий g cc git, но не смог найти отправную точку для такой модификации.

Answer 1

Это все немного теоретически, так как я никогда не пытался выполнить полную настройку. Но я думаю, что это был бы разумный проект.

G CC внутренности описаны в руководстве G CC внутренностей . Возможно, вам не нужно читать все это подробно, но вы должны хотя бы попытаться получить представление о структуре basi c. Все это легко настраивается.

Соглашение о вызовах настраивается в «описании машины» , которое является частью back end . Наиболее важной частью для типа изменений, которые вы просматриваете, является описание макета стека и соглашения о вызовах . Например, вы можете изменить способ, которым функции возвращают скалярные значения, используя TARGET_FUNCTION_VALUE hook , хотя вам, вероятно, также потребуется изменить другие части описания машины для правильной обработки назначения регистра.

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