В чем смысл этих операторов языка ассемблера?

Я заметил некоторые странно выглядящие заявления, когда я просмотрел какой-то c-код в разборке. Операции произошли непосредственно перед вызовом функции. Так что я удалил весь код из моей программы просто оставить пустую основную функцию, как это -В чем смысл этих операторов языка ассемблера?

У меня есть пустая основная функция, как это -

int _tmain(int argc, _TCHAR* argv[]) 
{ 
    return 0; 
}

Но когда я посмотрел на разборке заявления сборочного в вопросе по-прежнему настоящее время. Так кто-нибудь знает, для чего предназначены эти утверждения?

int _tmain(int argc, _TCHAR* argv[]) 
{ 
00411350 push  ebp 
00411351 mov   ebp,esp 
00411353 sub   esp,0C0h 
00411359 push  ebx 
0041135A push  esi 
0041135B push  edi 
0041135C lea   edi,[ebp-0C0h] 
00411362 mov   ecx,30h 
00411367 mov   eax,0CCCCCCCCh 
0041136C rep stos dword ptr es:[edi] 
return 0; 
0041136E xor   eax,eax 
}

Заявление о которых идет речь

00411362 mov   ecx,30h 
00411367 mov   eax,0CCCCCCCCh 
0041136C rep stos dword ptr es:[edi]

источник

2012-01-12 Jim_CS

Возможный дубликат [Почему мы выделяем 12 байтов для каждой переменной?] (Http://stackoverflow.com/questions/8033353/why-do-we-allocate-12-bytes-for-each-variable) –

Этот код заполняет рамку стека шаблоном (0xcc). exc содержит количество слов для заполнения, «eax» - это шаблон. Архитектура Intel rep opcode - «Повторить префикс операции строки». Скорее всего, это шаблонный код, который имел бы смысл в полной функции (возможно, устранение локальных переменных, создание умышленно плохих данных для неинициализированных переменных). Здесь кадр стека немедленно уничтожается при выходе, и код бесполезен.

О чем беспокоиться.

источник

2012-01-12 00:21:49 Bryce

Они некоторый избыточный код, который включен в отладочной версии. Похоже, для некоторых проверок ошибок. Они не выделяются в версиях Release.

источник

2012-01-12 00:18:17

Мне кажется, что он пишет поверх стека, когда программа завершается ... это имеет смысл в качестве меры предосторожности в случае, если какие-либо важные данные остаются там как мусор.

EDIT: Как указано в комментариях, это похоже на код установки, поэтому, вероятно, это не причина (я подозреваю, что это для целей отладки). Однако я оставил ответ здесь для справки, поскольку он может быть актуальным и в других ситуациях.

источник

2012-01-12 00:19:51 mikera

Это не похоже на вещь безопасности. Это больше похоже на попытку установить буфер «плохих» данных. Вероятно, так, что это очевидно, когда программа пытается читать неинициализированные данные. (Когда вы видите '0xcccccccc' в своих переменных, скорее всего, вы перепутались. И я уверен, что если вы попытаетесь использовать это значение в качестве указателя, что-то сломается.) – cHao

Знает ли кто-то точно знает, почему компилятор ставит это здесь? Этот код находится в каждой основной функции, поэтому для этого есть какая-то законная причина. И я не думаю, что это имеет какое-то отношение к перезаписи стека, когда программа завершается - этот код помещается до того, как функциональные параметры помещаются в стек, и функция вызывается. –

Да ... это часть кода запуска, а не очистки. Как я уже сказал, это, вероятно, для целей отладки, так что чтение из неинициализированных локальных переменных становится более очевидным. – cHao

В сборке Debug компилятор Visual C++ заполняет пространство стека, выделенное для локальных переменных, с помощью шаблона 0xCC, так что неинициализированные переменные могут быть легко распознаны при отладке. Существуют и другие магические значения, используемые компилятором и/или ОС для отладки; отметьте this list в Википедии.

Я не уверен, почему компилятор решил выделить пространство стека в этой функции; возможно, это нечто специфичное для обработки функции main.

источник

2012-01-12 15:03:54

В чем смысл этих операторов языка ассемблера?

ответ

Смежные вопросы