Dynamiczna alokacja pamięci. Reprezentacja w exe.

pytanie zadane 2 lipca 2018 w C i C++ przez Hiskiel Pasjonat (22,830 p.)
zamknięte 2 lipca 2018 przez Hiskiel

Witam.

Jak wygląda dynamicznie alokowana pamięć w exe? Mianowicie z tego co mi wiadomo. W ogromnym uproszczeniu header exe wygląda tak:

MZ SRUTUTU
Informacje gdzie zaczyna się kod i gdzie zaczynają się dane, 
gdzie kończy się kod
SRUTUTU
DANE
KOD
tutaj coś tam jeszcze było, chyba tabela importów

Gdy mamy załóżmy taki program w wymyślonym języku:

start:
create int a=100;
create int b=11;

Nie czytajcie tych głupot > [To wiemy, że kod będzie się zaczynał na offsecie rozmiar nagłówka + rozmiar danych

Jednakże podczas dynamicznej alokacji, która następuje w TRAKCIE działania programu, może być różnie. Np. program typu baza danych, gdzie przed zapisaniem do pliku wszystkie dane znajdują się w RAM'ie. Użytkownik może sobie zażyczyć 2000 elementową tablicę, np. na wszystkich klientów. Co wtedy?] < Nie czytajcie tych głupot

Gdyby ktoś byłby w stanie mi to wytłumaczyć byłbym bardzo wdzięczny.

Pozdrawiam.

komentarz zamknięcia: adrian17 rozwiał moje wątpliwości.

komentarz 2 lipca 2018 przez criss Mędrzec (172,590 p.)

Jednakże podczas dynamicznej alokacji, która następuje w TRAKCIE działania programu, może być różnie.

Nie mam pojęcia gdzie widzisz problem.. Co może być różnie?
Co w ogóle ma alokacja pamięci do tego gdzie jest kod programu w pamięci?

komentarz 2 lipca 2018 przez Hiskiel Pasjonat (22,830 p.)

To, że jeśli potrzeba zaalokować 100Bajtów, to kod zacznie się [rozmiar headera + rozmiar danych, czyli 100], jeśli dane mają inną wielkość, to kod zacznie się na innym offsecie. A problem jest dlatego, że w headerze trzeba zadeklarować gdzie ten kod się zaczyna, AddressOfEntryPoint.

1	komentarz 2 lipca 2018 przez criss Mędrzec (172,590 p.) Mylisz blok .data (tam gdzie są zmienne globalne) i sterte :D Doczytaj. Już pomijając, że istnieje jeszcze stos.

komentarz 2 lipca 2018 przez adrian17 Ekspert (344,860 p.)

To, że jeśli potrzeba zaalokować 100Bajtów, to kod zacznie się [rozmiar headera + rozmiar danych, czyli 100]

Alokowanie pamięci przez program (dynamicznie lub nie) nie ma żadnego związku z pamięcią zajmowaną przez kod programu. Dane alokowane są albo na stosie (zwykłe zmienne), na stercie (dynamiczna alokacja) lub są zakodowane w osobnej sekcji (stałe, zmienne globalne). Kod programu jest w zupełnie innej sekcji.

komentarz 2 lipca 2018 przez Hiskiel Pasjonat (22,830 p.)

No dobra, ogólnie chodziło mi o coś innego:

Header ...0
Kod zaczyna się tam (10)5
Header ...8
DANE 9
tam 10
(Te liczby to offset chyba w maksalnym uproszczeniu)

Gdybym miał teraz pobrać od użytkownika jakiegoś stringa, a byłby tam, gdzie dane to offset kodu byłby inny. Ale teraz wiem, że stringi są na samym końcu programu. Dzięki.

https://imgur.com/a/yfeuZnI

komentarz 2 lipca 2018 przez adrian17 Ekspert (344,860 p.)

Gdybym miał teraz pobrać od użytkownika jakiegoś stringa

Nie byłby "na końcu programu".

Stałe "stringi" w programie byłyby w osobnej sekcji w .exe, tak.

Globalny char[100] miałby odpowiadającą mu sekcję w .exe, tak.

Tablica char[100] w funkcji byłaby na stosie - brak związku z "pozycją w programie" i offsetami binarki.

Pamięć `new char[100]` zaalokowana dynamicznie w funkcji byłaby na stercie - brak związku z "pozycją w programie" i offsetami binarki.

komentarz 2 lipca 2018 przez Hiskiel Pasjonat (22,830 p.)

Dobra, przepraszam. Wygłupiłem się. Tak długo lamentowałem na headerem exeka i zastanawiałem się nad Linuxem, że mi mózg zlasowało. Dziękuję bardzo za rozwianie moich wątpliwości.. ale tak naprawdę. Pozdrawiam.

komentarz 3 lipca 2018 przez Hiskiel Pasjonat (22,830 p.)

Dobra, jeszcze jedno pytanie. Podobno zmienne lokalne są wrzucane na stos. Ale jak potem z tego stosu są zdejmowane? Zadeklaruję 20 zmiennych, co wtedy? Chcę się dostać do 19. Nie rozumiem do końca tego zamysły.

komentarz 3 lipca 2018 przez criss Mędrzec (172,590 p.)
edycja 3 lipca 2018 przez criss

Alokacja na stosie odbywa się poprzez "przesuwanie wskaźnika stosu". Tzn. jeśli tworzysz np. 3 zmienne lokalne: int, int, long long, to potrzebujemy 4+4+8=16 bajtów. Więc wskaźnik stosu jest przesuwany o 16 [adresów]. Czasami ilość zarezerwowanej pamięci może być troche większa, żeby zmienne były pod adresami aligned (po polsku chyba wyrównane?) do liczby podzielnej przez jakąś liczbe. Dzieje się tak dlatego, żeby zminimalizować ilość pobrań danych z pamięci poprzez szyne danych (najlepiej jakbyś doczytał jeśli cie to interesuje, bo tu jest jeszcze troche do napisania).
Zdejmowanie ze stosu odbywa się wtedy oczywiście przez przesnięcie wskaźnika stosu z powrotem.

https://godbolt.org/g/acYTbr

int main()
{
    int a = 4, b = rand();
    long long c = 8;
}

jest tłumaczone na:

main:
  push rbp ; zapamiętujemy sobie wartość rejestru rbp w pamięci wrzucając jego wartość na stos
  mov rbp, rsp ;kopiujemy rejestr wskaznika stosu do rbp
  sub rsp, 16 ; manipulujemy sobie wskazkiem stosu
  ; ^^^^ to jest alokacja 16 bajtów na stosie
  mov DWORD PTR [rbp-4], 4
  call rand ; wartosc zwrocona z rand znajduje sie w rej. eax
  mov DWORD PTR [rbp-8], eax
  mov QWORD PTR [rbp-16], 8
  mov eax, 0
  leave ; ta instrukcja realizuje przywracanie wartości wskaźnika stosu (kopiuje rbp do rsp)
  ; oraz nastepnie przywraca wartość rbp z pamięci
  ; czyli w skrocie zdejmuje zmienne lokalne ze stosu
  ret

(gcc8.1, x86-64)
Zauważ, że na x86 stos "rośnie w dół" dlatego rezerwacja pamięci odbywa się poprzez `sub` a nie `add`
* wszystko powyższe jest napisane w kontekście x86

komentarz 3 lipca 2018 przez Hiskiel Pasjonat (22,830 p.)

Dalej nie rozumiem pewnej rzeczy.

1. "* wszystko powyższe jest napisane w kontekście x86", ale nic mi nie wiadomo o rejestrach rbp, rsp itd. Z tego co wiem są tylko EAX, EBX, ECX, EDX, AX, BX, CX, DX, AH, AL, BH, BL, CH, CL, DH, DL. W x86 wskaźnikiem na stos jest bodajże ESP.

2. sub rsp, 16. Ok. "Rezerwujemy 16 bajtów", to po co potem dajemy te wszystkie zmienne do rejestru rbp, poza tym. Do rejestru da się wrzucić więcej niż jedną wartość?

komentarz 3 lipca 2018 przez criss Mędrzec (172,590 p.)
edycja 3 lipca 2018 przez criss

rbp i rsp to odpowiedniki ebp i esp w trybie 64bit (dolne 32bity rbp to ebp.. itd).

po co potem dajemy te wszystkie zmienne do rejestru rbp

Nie mam pojęcia o co ci chodzi.

mov QWORD PTR [rbp-16], 8

oznacza "zapisz wartość `8` na 8 bajtach w pamięci zaczynając od adresu określonego {wartość w rbp} pomniejszona o 16.

komentarz 3 lipca 2018 przez Hiskiel Pasjonat (22,830 p.)

 sub rsp, 16 ; alokujemy
  ; ^^^^ to jest alokacja 16 bajtów na stosie
  mov DWORD PTR [rbp-4], 4   ----|
  call rand                                        |
  mov DWORD PTR [rbp-8], eax     | - wszystko trafia do rbp, jakimś magicznym cudem.
  mov QWORD PTR [rbp-16], 8  ---|

komentarz 3 lipca 2018 przez criss Mędrzec (172,590 p.)

Edytowalem komentarz wyzej.

komentarz 3 lipca 2018 przez Hiskiel Pasjonat (22,830 p.)

Dalej nie do końca rozumiem.. Bo skoro "zaczynając od adresu określonego", to w rbp musiałby być adres stosu, a w rbp jest zawartość stosu..

komentarz 3 lipca 2018 przez criss Mędrzec (172,590 p.)

W rbp jest adres stosu (za sprawą mov rbp, rsp). Nawet nie wiem co to znaczy, że w rbp jest zawartość stosu :D

komentarz 3 lipca 2018 przez Hiskiel Pasjonat (22,830 p.)

To w takim razie to nie powinno być mov rbp, [rsp] ?

komentarz 3 lipca 2018 przez criss Mędrzec (172,590 p.)

Nie, kwadratowe nawiasy oznaczają odwołanie do pamięci pod adresem określonym wewnątrz kwadratowych nawiasów

mov rbp, [rsp] zapisałoby w rbp 8 bajtów z pod adresu zapisanego w rsp

komentarz 3 lipca 2018 przez Hiskiel Pasjonat (22,830 p.)

No... Właśnie.

mov rbp, [adres rsp]

komentarz 3 lipca 2018 przez criss Mędrzec (172,590 p.)

mov rbp, [rsp] zapisałoby w rbp 8 bajtów z pod adresu zapisanego w rsp.

Wybacz, ale chyba nie potrafie ci tego wytłumaczyć jeśli teraz nie rozumiesz.. Ale dobra rada: nie kłóć się z kompilatorem jaki kod asm powinien generować :P

komentarz 3 lipca 2018 przez Hiskiel Pasjonat (22,830 p.)

A w ten sposób..

Rozumiem. [reg] to coś w stylu jak w c++ int* b = *a;

a mov rbp, rsp int* b = &a;

Rozumiem..

A a propos tego kompilatora. Nie chcę się z nim kłócić. Głównym zamysłem tego mojego kompilatora (to miałby być taki o projekt) było, żeby tłumaczyć kod na asm, każda libka byłaby w asmie napisana, a potem na opcode. Wygenerować elfa, czy tam exe i sruuu.