Ramka stosu na przykładzie funkcji C++

Mam taki krótki kod w C++:

#include <iostream>

using namespace std;

int triangle(int width, int height)
{
    int array[5] = {0,1,2,3,4};
    int area;
    area = width * height / 2;
    return area;
}

int main()
{
    triangle(2, 2);
    return 0;
}

Disassembler funkcję tłumaczy tak:

0x401350	push   ebp
0x401351	mov    ebp,esp
0x401353	sub    esp,0x20
0x401356	mov    DWORD PTR [ebp-0x18],0x0
0x40135d	mov    DWORD PTR [ebp-0x14],0x1
0x401364	mov    DWORD PTR [ebp-0x10],0x2
0x40136b	mov    DWORD PTR [ebp-0xc],0x3
0x401372	mov    DWORD PTR [ebp-0x8],0x4
0x401379	mov    eax,DWORD PTR [ebp+0x8]
0x40137c	imul   eax,DWORD PTR [ebp+0xc]
0x401380	mov    edx,eax
0x401382	shr    edx,0x1f
0x401385	add    eax,edx
0x401387	sar    eax,1
0x401389	mov    DWORD PTR [ebp-0x4],eax
0x40138c	mov    eax,DWORD PTR [ebp-0x4]
0x40138f	leave
0x401390	ret

Z tego co rozpisuje sobie na kartce stos wygląda tak:

    -32      -28       -24    -20     -16    -12    -8      -4      0       +4    +8      +12
  [     ][local area][  0  ][  1  ][   2  ][  3  ][  4  ][  ?  ][OLD EBP][ RET ][HEIGHT][WIDTH]
  ^                                                             ^
 esp                                                           ebp

Te liczby na górze to pozycja od epb, któremu został przypisany adres poprzedniego esp instrukcją mov ebp, esp.
I jeśli dobrze to rozpisałem to zastanawia mnie co znajduje się na pozycji [epb-4] i dlaczego wskaźnik esp powędrował, aż na pozycję ebp-32, skoro jest tylko jedna zmienna lokalna area, która powinna być pod adresem ebp-28. I dlaczego ta zmienna lokalna nie jest wykorzystywana w dalszych instrukcjach tylko zamiast tego inne rejestry?

Nie znam się ale wydaje mi się że chodzi o to
https://en.m.wikipedia.org/wiki/Data_structure_alignment

Przez to wyrównanie adres jest na pozycji 32

Tak, ogólnie operując na pamięci kompilatory wyrównują adresy do określonej pełnej liczby bajtów (często do 8B, ale czasami też do innych wielokrotności 2, np do 4B - zależy od architektury).

Jeśli chodzi i disassembly - pewnie kompilowałeś z optymalizacjami, więc kompilator słusznie uznał, że nie ma sensu odkładać wyniku w jakieś-tam odrębne miejsce w pamięci, skoro można od razu zwrócić ;) nie pamiętam dokładnie jak to jest w x86 a jak w innych assembly, ale zwykle wartość zwracana (lub jej adres) jest umieszczana w określonym rejestrze lub w określonym miejscu na stosie.

Gdybyś dla odmiany skompilował to bodajże z -O0, kompilator powinien niemal po każdej operacji na rejestrach zrzucić ich wartość do pamięci, a przed każdym użyciem załadować ponownie (to się chyba nazywało memory spilling). Gdybyś operował na naprawdę wielu zmiennych i zabrakło by wolnych rejestrów ogólnego przeznaczenia, możliwe że wartość z wynikiem została by odłożona gdzieś na stosie. O ile użył byś do czegoś tych obliczeń, bo gdyby kompilator uznał że są zbyteczne prawdopodobnie zostały by wyrzucone i/lub uproszczone w trakcie optymalizacji ;)

@superdurszlak: Flagi do debugowania nie wpływają na postać kodu wynikowego, poza tym się zgodzę. Na x86 wartość zwracana znajduje się w rejestrze eax jeśli jest niewiększa niż 4 bajty, a w przeciwnym wypadku funkcja dostaje jeden "dodatkowy" argument - pierwszym argumentem staje się wskaźnik na miejsce gdzie zapisać wartość wynikową.

Wszystko jest opisane tutaj w tym PDFie, od strony 40.
http://www.sco.com/developers/devspecs/abi386-4.pdf

Na marginesie, zupełnie nie rozumiem po co uczyć się teraz 32 bitowego assemblera zamiast wersji 64 bitowej. Nie kojarzę kiedy ostatnio uruchamiałem jakiś kod 32 bitowy poza starymi grami. 64 bitowa wersja jest również w wielu aspektach prostsza (np. łatwiej odgadnąć jakie argumenty przyjmuje funkcja, gdyż pierwsze 6 argumentów jest odkładane w rejestrach a nie na stosie, zatem w momencie wywołania zazwyczaj od razu widać co w tych rejestrach jest umieszczane, w.p.p. do stosu na którym potencjalnie mogły być już odłożone oczekiwane wartości.

enedil napisał(a):

Na marginesie, zupełnie nie rozumiem po co uczyć się teraz 32 bitowego assemblera zamiast wersji 64 bitowej...

To ze względu na to, że w języku polskim brakuje dobrych publikacji o x64, a w dodatku w ręce wpadła mi książka "Shellcoders Handbook", która omawia architekturę x32.

enedil napisał(a):

Na marginesie, zupełnie nie rozumiem po co uczyć się teraz 32 bitowego assemblera zamiast wersji 64 bitowej. Nie kojarzę kiedy ostatnio uruchamiałem jakiś kod 32 bitowy poza starymi grami. 64 bitowa wersja jest również w wielu aspektach prostsza

A w wielu jest trudniejsza, jak choćby kolejne rejestry wzdłuż i wszerz.

(np. łatwiej odgadnąć jakie argumenty przyjmuje funkcja, gdyż pierwsze 6 argumentów jest odkładane w rejestrach a nie na stosie

Tya, tylko zapamiętaj kolejność tych rejestrów. W dodatku w 32-bitach faktycznie da się ręcznie kodzić i potem to debugować, podczas gdy 64-bitowy calling convention (przynajmniej pod Windows) przewiduje w zasadzie wyłącznie generowanie kodu przez kompilatory. Spróbuj napisać z palca i bez tony makr proceduralny kod tak by spełnić wszystkie konwencje by w razie wyjątku debugger pokazał sensowny call stack.

0x401389    mov    DWORD PTR [ebp-0x4],eax
0x40138c    mov    eax,DWORD PTR [ebp-0x4]

Najpierw z rejestru eax, który służył do obliczeń wrzucany jest wynik pod adres [ebp-4], a następnie do rejestru eax wrzucany jest z powrotem ten wynik z [ebp-4].
Rozumiem, że te dwie linie są zbędne? I ten adres [ebp-4] mógłbym sobie darować, gdybym miał sam napisać taką funkcję w asm.

I mam jeszcze jedno pytanie. Kiedy ustawiam breakpoint na funkcję, która jest przed funkcją main, to disassembler działa jakby na sucho, bez argumentów, a jak breakpoint ustawiam na instrukcji zaraz po jej wywołaniu to wyświetla tylko:

call   0x401350 <triangle(int, int)>

Można jakoś podejrzeć działanie funkcji z przekazanymi argumentami? Bo te przesunięcia bitowe shr i sar wydają się dość dziwne i czy w przypadku wywołania funkcji

triangle(2, 2);

te przesunięcia będą inne?