Может ли кто-нибудь помочь мне интерпретировать эту простую разборку с WinDbg?

Ответ 1

Я добавил аннотацию ассемблеру, надеюсь, это поможет вам немного. Строки, начинающиеся с 'd', являются строками кода отладки, строки, начинающиеся с 'r', - это строки кода проверки времени выполнения. Я также добавил, что, как мне кажется, отладка с версией проверки исполнения и версией будет выглядеть.

  ; The ebp register is used to access local variables that are stored on the stack, 
  ; this is known as a stack frame. Before we start doing anything, we need to save 
  ; the stack frame of the calling function so it can be restored when we finish.
  push    ebp                   
  ; These two instructions create our stack frame, in this case, 192 bytes
  ; This space, although not used in this case, is useful for edit-and-continue. If you
  ; break the program and add code which requires a local variable, the space is 
  ; available for it. This is much simpler than trying to relocate stack variables, 
  ; especially if you have pointers to stack variables.
  mov     ebp,esp             
d sub     esp,0C0h              
  ; C/C++ functions shouldn't alter these three registers in this build configuration,
  ; so save them. These are stored below our stack frame (the stack moves down in memory)
r push    ebx
r push    esi
r push    edi                   
  ; This puts the address of the stack frame bottom (lowest address) into edi...
d lea     edi,[ebp-0C0h]        
  ; ...and then fill the stack frame with the uninitialised data value (ecx = number of
  ; dwords, eax = value to store)
d mov     ecx,30h
d mov     eax,0CCCCCCCCh     
d rep stos dword ptr es:[edi]   
  ; Stack checking code: the stack pointer is stored in esi
r mov     esi,esp               
  ; This is the first parameter to printf. Parameters are pushed onto the stack 
  ; in reverse order (i.e. last parameter pushed first) before calling the function.
  push    offset SimpleDemo!`string' 
  ; This is the call to printf. Note the call is indirect, the target address is
  ; specified in the memory address SimpleDemo!_imp__printf, which is filled in when
  ; the executable is loaded into RAM.
  call    dword ptr [SimpleDemo!_imp__printf] 
  ; In C/C++, the caller is responsible for removing the parameters. This is because
  ; the caller is the only code that knows how many parameters were put on the stack
  ; (thanks to the '...' parameter type)
  add     esp,4                 
  ; More stack checking code - this sets the zero flag if the stack pointer is pointing
  ; where we expect it to be pointing. 
r cmp     esi,esp               
  ; ILT - Import Lookup Table? This is a statically linked function which throws an
  ; exception/error if the zero flag is cleared (i.e. the stack pointer is pointing
  ; somewhere unexpected)
r call    SimpleDemo!ILT+295(__RTC_CheckEsp)) 
  ; The return value is stored in eax by convention
  xor     eax,eax               
  ; Restore the values we shouldn't have altered
r pop     edi
r pop     esi
r pop     ebx                   
  ; Destroy the stack frame
r add     esp,0C0h              
  ; More stack checking code - this sets the zero flag if the stack pointer is pointing
  ; where we expect it to be pointing. 
r cmp     ebp,esp               
  ; see above
r call    SimpleDemo!ILT+295(__RTC_CheckEsp) 
  ; This is the usual way to destroy the stack frame, but here it not really necessary
  ; since ebp==esp
  mov     esp,ebp               
  ; Restore the caller stack frame
  pop     ebp                   
  ; And exit
  ret                           


  ; Debug only, no runtime checks  
  push    ebp                   
  mov     ebp,esp             
d sub     esp,0C0h              
d lea     edi,[ebp-0C0h]        
d mov     ecx,30h
d mov     eax,0CCCCCCCCh     
d rep stos dword ptr es:[edi]   
  push    offset SimpleDemo!`string' 
  call    dword ptr [SimpleDemo!_imp__printf] 
  add     esp,4                 
  xor     eax,eax               
  mov     esp,ebp               
  pop     ebp                   
  ret                             


  ; Release mode (I'm assuming the optimiser is clever enough to drop the stack frame when there no local variables)
  push    offset SimpleDemo!`string' 
  call    dword ptr [SimpleDemo!_imp__printf] 
  add     esp,4                 
  xor     eax,eax               
  ret                               

Ответ 2

Номер один, ваш код main() неправильно сформирован. Это не возвращает того, что вы обещали вернуться. Исправляя этот дефект, получаем:

#include 
int main(int argc, char *argv[])
{
    ::printf("\nHello,debugger!\n");
    return 0;
}

Кроме того, очень странно видеть #include <stdio.h> в программе на С++. Я считаю, что вы хотите #include <cstdio>

Во всех случаях пространство должно быть сделано в стеке для аргументов и для возвращаемых значений. main() возвращаемое значение требует пространства стека. main() s, который нужно сохранить во время вызова printf(), требует пространства стека. Для аргументов printf() требуется пространство стека. printf() Возвращаемое значение требует пространства стека. Это то, что делает кадр стека 0c0h.

Первое, что происходит, - это то, что входящий базовый указатель копируется в верхнюю часть стека. Затем новый указатель стека копируется в базовый указатель. Мы будем проверять позже, чтобы убедиться, что стек вернется туда, откуда он начал (потому что вы включили проверку времени исполнения). Затем мы создаем кадр стека (0C0h bytes long) для хранения наших аргументов context и printf() во время вызова printf(). Переходим к printf(). Когда мы вернемся, мы перепрыгиваем через возвращаемое значение, которое вы не проверяли в своем коде (единственное, что осталось на его фрейме), и убедитесь, что стек после вызова находится в том же месте, что и до вызова. Мы отбрасываем контекст обратно со стека. Затем мы проверяем, что конечный указатель стека соответствует значению, которое мы сохранили в начале. Затем мы вытаскиваем предыдущее значение базового указателя с самого верха стека и возвращаемся.

Ответ 3

Это код, который вставляется компилятором при построении с проверкой времени выполнения (/RTC). Отключите эти параметры, и он должен быть более четким. /GZ также может вызывать это в зависимости от вашей версии VS.

Ответ 4

40 байтов - это наихудшее распределение стека для любой вызываемой или вызываемой функции. Это объясняется в славных деталях здесь.

Для чего это пространство зарезервировано в верхней части стека? Во-первых, пространство создается для любых локальных переменных. В этом случае функция FunctionWith6Params() имеет два. Однако эти две локальные переменные учитывают только 0x10 байт. Какова сделка с остальной частью пространства, созданной в верхней части стека?

На платформе x64, когда код подготавливает стек для вызова другой функции, он не использует push-команды для установки параметров в стек, как это обычно бывает в коде x86. Вместо этого указатель стека обычно остается фиксированным для определенной функции. Компилятор просматривает все функции, которые выполняет код в текущей функции, он находит одно с максимальным количеством параметров, а затем создает достаточное пространство в стеке для размещения этих параметров. В этом примере функция FunctionWith6Params() вызывает printf(), передавая ему 8 параметров. Так как это вызванная функция с максимальным количеством параметров, компилятор создает 8 слотов в стеке. Верхние четыре слота в стеке будут тогда домашним пространством, используемым любыми функциями вызовов FunctionWith6Params().

Ответ 5

Для записи я подозреваю, что ILT означает "Инкрементное связывание Thunk".

Способ инкрементной привязки (и Edit & Continue) работает следующим образом: компоновщик добавляет слой косвенности для каждого вызова через thunks, которые сгруппированы в начале исполняемого файла, и добавляет после них огромное зарезервированное пространство. Таким образом, когда вы обновляете обновленный исполняемый файл, он может просто поместить любой новый/измененный код в зарезервированную область и исправить только затронутые thunks, не изменяя остальную часть кода.