Приветствую собратьев ассемблерщиков!
Недавно решил поиграться 64 битным асмом, и засыпался на банальнейшем хелловорлде


Вроде ж ничего криминального, но программа упорно падает где-то в системных недрах:


Эксепшен генерится ммх командой, которая ожидает, что записываемый адрес будет кратен 0х10
Таким образом, добавив в начало своей программы выравнивание стэка "and rsp, -16", я от проблемы избавился.

А теперь, собственно, вопрос: как правильно оформлять стек в х64?
Допустим, я вызываю апи функцию, которой нужно передать больше 4ёх аргументов - они пойдут через стэк.
Выравнивать нужно до стековых аргументов, или так, чтобы в итоге только 0x20 фрейм был выравнен?
Какие еще есть грабли, о которых нужно знать, чтобы писать на х64 асме?

[имхо]стандартное соглашение о вызовах - просто жесть дичайшая.
Вместо того, чтобы просто толкать первые четыре аргумента в стэк, они пишутся в регистры,
но вызывающая сторона всё равно должна выделить 0х20 байт в стэке, куда вызванная
функция сохраняет свои аргументы. О чём они, бл***, думали?[/имхо]



cea1_16.08.2018_EXELAB.rU.tgz - buggy.exe

| Сообщение посчитали полезным:

Что студийный компиль нагенерил:

как-бэ fastcall

| Сообщение посчитали полезным:

ELF_7719116 пишет:
как-бэ fastcall
Обычный для x64 calling convention

-=AkaBOSS=- пишет:
Вместо того, чтобы просто толкать первые четыре аргумента в стэк, они пишутся в регистры,
но вызывающая сторона всё равно должна выделить 0х20 байт в стэке, куда вызванная
функция сохраняет свои аргументы. О чём они, бл***, думали?
Вообще-то это очень мудрое решение с точки зрения глобальной оптимизации кода. Стековые фреймы могут быть выделены один раз, функции можно вызывать много раз и разные.
Просто это всё не предназначено чтобы вручную писать на ассемблере. Юзайте си.

-----
PGP key <0x1B6A24550F33E44A>

| Сообщение посчитали полезным:

Идея понятна?
С такой мишурой можно столкнуться и в х32, с Zw* и Nt* функциями.

-----
2 оттенка серого

| Сообщение посчитали полезным:

Есть отличная статья про переход на x64 https://www.codeproject.com/Articles/17263/Moving-to-Windows-Vista-x64
Это стандартная (и единственная) конвенция вызовов в x64. Всяко полезно ознакомиться.

| Сообщение посчитали полезным: ajax, -=AkaBOSS=-, plutos

-=AkaBOSS=-
В х64 необходимо выравнивать стек на 16 байт, в противном случае будут проблемы описанные тобой.
Для решения оной юзаем макрос


В начале функции memalign rsp,16

| Сообщение посчитали полезным:

BlackCode, да причину-то я и сам понял, еще до создания темы.
Другое дело что мне было неясно, как при этом поступать с аргументами, которые передаются через стэк. Как выравнивать - до них или после.
Archer дал ссылку на статью, где это проясняется - выделяем фрейм размером <кол-во стековых аргументов>*8+0х20, округляем rsp вниз до 0х10 и стэковые аргументы не толкаем, а вписываем как-то так: mov [rsp+20h], arg5; mov [rsp+28h], arg6; и т.д.
И разумеется, перед каждым таким фреймом нужно сохранять rsp, так как после округления его уже простой математикой не восстановишь.

| Сообщение посчитали полезным:

-=AkaBOSS=- пишет:
его уже простой математикой не восстановишь
Инструкцией leave такое округление восстановится само.

-----
2 оттенка серого

| Сообщение посчитали полезным:

f13nd пишет:
Инструкцией leave такое округление восстановится само.
если регистр не был предварительно сохранён - нет

f13nd пишет:
это всяко лучше
ну вообще в целом это уже зависит от того, как и для чего использовать стэк)

| Сообщение посчитали полезным:

-=AkaBOSS=- пишет:
если регистр не был предварительно сохранён - нет
это всяко лучше, чем "перед каждым таким фреймом сохранять rsp"

-----
2 оттенка серого

| Сообщение посчитали полезным:

-=AkaBOSS=-

Ты какой компилятор используешь?
Я UASM64, ранее JWASM..
Как правило компилятор сам заботится об сохранении параметров и выделении стека под аргументы.
В заголовке у меня такие параметры


| Сообщение посчитали полезным:

Leave-это просто автоматизированный аналог mov Xsp,Xbp; pop Xbp. Если в Xbp никто до этого не положил Xsp, будет мусор.
И в x64 фреймы используются достаточно нечасто в скомпилированном коде. В том числе и потому, что никто не делает там and Xsp,imm. А не делает потому, что на входе в функцию стек уже определённым образом выровнен, чем и пользуются.

| Сообщение посчитали полезным:

И из за компилерных фич трассировка ветвлений(backtrace) выполняется через брутфорс адресов

-----
vx

| Сообщение посчитали полезным:

BlackCode пишет:
UASM64
Не подскажешь поддерживает ли этот компилятор COMDAT сегменты?

-----
PGP key <0x1B6A24550F33E44A>

| Сообщение посчитали полезным:

ntldr пишет:
Не подскажешь поддерживает ли этот компилятор COMDAT сегменты?

Ассемблер, UASM64 ешё не компилятор .. поэтому COMDAT в основном не поддерживает, только на уровне самих сегментов, точно так же, как и масм64. Пример для уасм можно посмотреть здесь - --> Link <--

-----
RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube

| Сообщение посчитали полезным:

Привет всем мимо проходящим
Также приветствую собратьев ассемблерщиков
Хотел спросить кто в какой программе любит кодить, как вам Sublime Text ?
Вроде как неплохой редактор, с очень удобной подсветкой синтаксиса и прочих плюшек

| Сообщение посчитали полезным:

HabibQq пишет:
Привет всем мимо проходящим
Дык ,по ходу это ты..

| Сообщение посчитали полезным:

HabibQq пишет:
Привет всем мимо проходящим
Также приветствую собратьев ассемблерщиков
Хотел спросить кто в какой программе любит кодить, как вам Sublime Text ?
Вроде как неплохой редактор, с очень удобной подсветкой синтаксиса и прочих плюшек

Мне лично Atom по душе...или Komodo Edit
Подсветка синтаксиса это не самое важное как мне кажется

| Сообщение посчитали полезным:

HabibQq пишет:
Также приветствую собратьев ассемблерщиков
Sublime Text поддерживает следующие форматы:
- C, CPP, H, HPP, INL, CC, D, ERL, DOT, HTML, HS, JAVA, JS, TEX, LISP, LUA, PL, PY, R, SQL, TCL, XML
Жалкая попытка "беспалевной" рекламы. Ну хоть бы тему правильно выбрал куда постить.

-----
2 оттенка серого

| Сообщение посчитали полезным: