Несмотря на то, что соглашение вызовов x64 резервирует небольшое пространство для параметров, вы не обязаны использовать его в таком качестве
Несмотря на то, что соглашение вызовов x64 резервирует место для размещения первых четырех параметров (переданных в регистрах), нет никаких требований относительно того, чтобы это место использовалось именно для передачи параметров. Это просто 32 байта памяти, доступной для временного использования вызываемой функцией.
У нас есть тестовая программа, которая работает корректно при отключенной оптимизации, но когда она скомпилирована с максимальным уровнем оптимизации, все сразу же идет наперекосяк. Вот эта функция не получает корректных значений параметров argc и argv:
int __cdecl wmain( int argc, WCHAR** argv ) { ... }При отключенной оптимизации генерируется корректный код:
mov [rsp+10h],rdx // argv mov [rsp+8],ecx // argc sub rsp,158h // локальные переменные mov [rsp+130h],0FFFFFFFFFFFFFFFEh ...Но когда мы запускаем компиляцию с оптимизацией, то происходит какая-то путаница:
mov rax,rsp push rsi push rdi push r13 sub rsp,0E0h mov qword ptr [rsp+78h],0FFFFFFFFFFFFFFFEh mov [rax+8],rbx // ??? должно быть ecx (argc) mov [rax+10h],rbp // ??? должно быть edx (argv)
Когда оптимизация отключена, компилятор Visual C++ x64 помещает все регистровые параметры в соответствующие слоты. У такого варианта есть приятный побочный эффект, заключающийся в небольшом упрощении отладки, но основная причина простоты отладки заключается в том, что вы отключили оптимизацию и теперь компилятор генерирует простой, прямолинейный код, без претензий на интеллектуальность.
Когда оптимизации включены, компилятор становится более агрессивным в отношении удаления ненужных операций и использования памяти для нескольких целей сразу, когда жизненные циклы переменных не пересекаются. Если он обнаруживает, что параметр argc не требуется сохранять в памяти (возможно, он поместит его в регистр), тогда он может использовать слот параметра argc для чего-нибудь другого, в данном случае он используется для сохранения значения rbx.
Вы можете наблюдать такое же поведение даже в x86-коде, когда память, используемая для передачи параметров, может быть повторно использована для других целей, после того как значение параметра больше не требуется в памяти. (Компилятор может загрузить значение в регистр и использовать его из регистра в оставшейся части функции, в этом случае участок памяти, в которой хранился этот параметр, становится неиспользуемым и может быть задействован для какой-либо другой цели).
С какой бы проблемой вы не столкнулись в вашей тестовой программе, в коде, приведенном в отчете о якобы дефекте нет никаких проблем с кодогенерацией. Проблема заключается в чем-то другом. (И скорее всего, она находится где-то в вашей программе. Не делайте поспешных выводов о том, что причина вашей проблемы — это ошибка в компиляторе).
Дополнение: В последующем уточнении (что, к сожалению, бывает очень редко) клиент признался, что проблема была в их программе. Они поместили вызов функции внутрь операции assert и отключили операции assert в неотладочной сборке (передав компилятору параметр /DNDEBUG), что означает, что в такой сборке эта функция никогда не вызывалась.
В продолжение темы: Сложности отладки оптимизированного x64-кода. Эта команда .frame /r действительно приводит к значительной экономии времени.