Туплю. Помогите разобраться (x64)

← →
Друг (2014-07-19 01:01) [0]

Задача элементарная
Заассемблировать такую функцию

var my_text: array[0..9] of WideChar = "some_text"#0; procedure Test; begin MessageBoxW(0, my_text, my_text, 0); end;

Работает
Пытаюсь заасемблировать - AccessViolation

procedure Test; asm xor rcx, rcx lea rdx, my_text lea r8, my_text xor r9, r9 call MessageBoxW end;

Смотрю дизассемблер стандартного кода, повторяю - работает
procedure Test; asm push rbp sub rsp,$20 mov rbp,rsp xor rcx, rcx lea rdx, my_text lea r8, my_text xor r9, r9 call MessageBoxW lea rsp,[rbp+$20] pop rbp end;

Объясните пожалуйста, что я делаю не так? По идее все 4 параметра должны укладываться в регистры, никакого стека быть не должно. Я в замешательстве.

← →
MessageBoxW (2014-07-19 08:14) [1]

WinAPI использует stdcall

← →
Друг (2014-07-19 08:31) [2]

это x64. тут все соглашения игнорируются

← →
megavoid © (2014-07-19 10:11) [3]

В х64 стэк есть, и при х64 call его надо выравнивать до 16 (sub rsp, $20);
http://msdn.microsoft.com/en-us/library/7kcdt6fy.aspx

← →
megavoid © (2014-07-19 10:13) [4]

The first parameter is the rcx register, the second one rdx, the third r8 and the fourth r9. Saying that the parameters registers are part of the stack frame, makes it also clear that any function that calls another child function has to initialize the stack providing space for these four registers, even if the parameters passed to the child function are less than four.
The initialization of the stack pointer is done only in the prologue of a function, it has to be large enough to hold all the arguments passed to child functions and it"s always a duty of the caller to clean the stack. Now, the most important thing to understand how the space is provided in the stack frame is that the stack has to be 16-byte aligned.
In fact, the return address has to be aligned to 16 bytes. So, the stack space will always be something like 16n + 8, where n depends on the number of parameters.

← →
Друг (2014-07-19 13:29) [5]

> megavoid ©

Спасибо!
Я в очередной раз охренел от этого x64
Оказывается перед вызовом функции нужно зарезервировать минимум 32 байта. На практике часто 40.

Ужас

← →
Друг (2014-07-19 13:42) [6]

Остаётся вопрос
Эта дребедень касается только ОС Windows или она во всех x86-64 системах?

← →
megavoid © (2014-07-19 16:58) [7]

Это "stdcall", в линупсах до затенения не дошли.

← →
Ega23 © (2014-07-19 23:47) [8]

> Остаётся вопрос
> Эта дребедень касается только ОС Windows или она во всех
> x86-64 системах?

Только гигабайтных xml-файлов. Касается.

← →
Германн © (2014-07-20 02:30) [9]

Удалено модератором

← →
Inovet © (2014-07-20 07:26) [10]

1 миллион вложенных вызовов сожрёт 32 мегабайта памяти из 32 гигабат, что составляет 0,1%. Ужас!!!

← →
Друг (2014-07-20 10:56) [11]

> megavoid © (19.07.14 16:58) [7]
> Это "stdcall", в линупсах до затенения не дошли.

Это не stdcall. Такая же фигня для register, cdecl, pascal...
Ты уверен, что под другими x64 ОС такого нет?

> Inovet © (20.07.14 07:26) [10]
> 1 миллион вложенных вызовов сожрёт 32 мегабайта памяти из
> 32 гигабат, что составляет 0,1%. Ужас!!!

Во-первых, стек 1мб по умолчанию (по крайней мере так было в x86). Во-вторых, ужас не размере занимаемой памяти, а в дикой нелогичности происходящего. Ну и неудобстве при ассемблировании конечно тоже.

← →
Друг (2014-07-20 10:59) [12]

Ну и потом не 32 мегабайта, а 48 :)

← →
megavoid © (2014-07-20 11:54) [13]

Что-то я в ABI вчера синим глазом воткнул, ega прав, конечно, есть.

← →
Друг (2014-07-20 11:55) [14]

> megavoid © (20.07.14 11:54) [13]

благорадствую

← →
Inovet © (2014-07-20 13:15) [15]

> [11] Друг (20.07.14 10:56)
> а в дикой нелогичности происходящего.

Ну да, так сходу непонятно - нафига оно надо.

> [11] Друг (20.07.14 10:56)
> Ну и неудобстве при ассемблировании конечно тоже.

А были же какие-то команды для формирования фрейма, что там с ними в х64?

← →
Друг (2014-07-20 14:08) [16]

> А были же какие-то команды для формирования фрейма, что
> там с ними в х64?

Если ты про enter и leave - то хз
Нормальные компиляторы их даже для x86 не используют :)
Думаю x64 эти команды остались без изменений

В целом хранение "фрейма" в ebp/rbp - это недостаток оптимизирующего компилятора. Даже древний компилятор Delphi x86 умеет адресовать локальные переменные от esp, не вводя в оборот ebp.

← →
jack128_ (2014-07-22 10:44) [17]

> Объясните пожалуйста, что я делаю не так?

вместо jmp вызываешь call

← →
Пит (2014-07-22 10:55) [18]

но ведь он написал:

>Смотрю дизассемблер стандартного кода, повторяю - работает

а там тоже jml нету

← →
jack128_ (2014-07-22 11:13) [19]

> Пит

И ? То что в стандартном коде нету jmp не означает, что вызов хвостового метода нельзя на jmp (без стека) сделать.

← →
Пит (2014-07-22 11:34) [20]

> То что в стандартном коде нету jmp не означает, что вызов
> хвостового метода нельзя на jmp (без стека) сделать.

но это также и не означает, что его нельзя call"ом сделать?

← →
Друг (2014-07-22 12:57) [21]

> jack128_ (22.07.14 10:44) [17]

Вопрос был не в том, как ухитриться
Вопрос был в том, почему логично написанный код не работает
И на этот вопрос уже получен ответ

>А были же какие-то команды для формирования фрейма, что там с ними в х64?
На х64 всё не так
http://www.transl-gunsmoker.ru/2008/12/5-amd64.html

← →
Обычный ламер (2014-07-22 16:54) [23]

Будьте добры, подскажите, если пишу приложения в своей системе под х32, они обязательно не будут работоспособны под х64?
Сврими комментариями Вы можете меня угробить :)
Спасибо

← →
junglecat (2014-07-22 16:57) [24]

> Сврими комментариями Вы можете меня угробить

это предложение? Тогда да, не будут )

Чего точно не будет работать - если DLL и EXE имеют разную разрядность.
Системные библиотеки поставляются в двух вариантах - и для 32, и для 64.
Возможно, что некоторые сервера могут не иметь 32-х разрядной подсистемы.

← →
имя (2014-07-23 19:44) [26]

Удалено модератором

Туплю. Помогите разобраться (x64) Найти похожие ветки