[c++] Stack 메모리와 Heap메모리에 관한 질문 (함수주소출력예

스택은 어떤 특정 시점 t1 에서 함수나 다른 프로세스로 컨텍스트 스위칭이 되면 기존에 작업하던 일감을 저장하기 위해서 사용하게 되죠. 이 부분이 심히 부족하게 만드는 경우(보통 recursive func에서 많이 발생)에는 SEGV(segmentation violation)을 유발하여 프로그램을 죽이기도 하죠. 따라서 프로그래머는 개발시 항상 이 영역을 생각해두고 개발해주는 것도 중요하죠. 무작정 스택을 소모하는 프로그램을 짜는 것은 좋지 않습니다.

힙은 가상메모리 영역에서 끌어다 쓰는 시스템에서 빌려주는 자원메모리라고 생각하시면 됩니다. 주로 paging을 통해서 입출력되는 메모리가 바로 힙메모리입니다. 이게 부족하게 되면 시스템이 전혀 작동이 안되어버리죠. 단순한 프로그램문제가 아니라 운영체제를 맛가게 할 수도 있습니다.

PS) Hip이 아니라 heap입니다. ^^

참고삼아 말하자면, Code영역, Data영역이라던가 Stack영역, heap영역 같은 구분은 특정 컴파일러(혹은 대다수의 컴파일러?)에나 해당하는 얘기입니다. 원래의 C/C++에는 그런 개념은 포함되어 있지 않으며, 단지 기억 수명(storage duration)과 통용범위(scope)라는 개념이 있을 뿐입니다.

개인적으로, 어떤 객체가 Stack영역에 저장되느냐 heap 영역에 저장되느냐 하는 것은 크게 중요한 사항은 아니라고 생각합니다. 그런 것들은 구현체가 알아서 할 일이고, 프로그래머는 단지 기억수명과 통용범위에 대한 것들만 알아두면 충분하다고 생각합니다.

물론 뭐든지 알아서 나쁠 것이 있겠습니까마는, 어떤 방식으로 설명하는게 낫냐고 한다면 저는 Stack이나 heap 등으로 설명하기보다는 기억수명과 통용범위란 개념으로 설명하는 쪽을 택하겠습니다.

순수한 소스와 코드라는 두가지 용어를 사용하셨는데, 만약 순수한 소스가 C 원본이라면, 잘못이해하신 것같습니다. 소스는 컴파일되면 더이상 실행 파일에 있지 않습니다. heap 영역과 스택은 컴파일되어 나온 파일안에는 없고, 실행되면서 잡히는 것입니다.
대게 실행파일이 로드되어 메모리가 잡히면, 데이터 영역의 뒷부분에 이어서 잡힙니다. 함수 즉 텍스트라고도하는 부분은 코드영역이 따로 있어 거기에 들어갑니다.

뭔가 많이 잘못된 듯한... :(
exe 파일에는 함수(extern static 모두), 전역변수, 정적변수 모두 들어갑니다.
데이터 영역은 크게 둘로 나뉩니다. data와 bss 이지요. 더 세분하면, data도 readonly 와 read/write 까지도 나누기도 합니다.
data에는 초기값이 있는 변수가 들어가며, 여기에는 문자열도 포함됩니다. bss에는 초기값이 없는 즉, 암시적으로 0으로 채워지는 변수들이 들어갑니다.

테스트 코드에서 함수 주소가 바뀐다고해서, stack이니 heap이니 나누는것은 옳지 않습니다. 컴파일되고 난뒤 배치가 그러할 뿐입니다.

두번째 질문에는 recursion이 만약 무한이라면, 무한의 stack이 필요하겠습니만, 다소 깊은 recursion이라면, 기본적으로 호출을 위해서는 stack을 늘여야하며, 만약 recursion되는 함수에서 계속 heap 할당을 한다면, heap도 늘여야하겠지요.

Code 영역이 아니라 data 영역에 잡히는 것입니다. 위에서도 언급하였지만, data 영역은 writable과 readonly가 따로 있습니다. 물론 없는 architecture도 있습니다. 하지만, 위의 예제에서 seg fault가 난것을 보면, 구분이 되어 있는 (요즘의 linux 같은) machine에서의 예제입니다.

컴파일러는 이것과 관련된 재밌는 option이 있습니다. string literal을 과연 어떤 data 영역에 둘것인가지요.

다음 코드를 살펴보시면, 위 코드를..

$ cat b.c
#include <stdio.h>


int main()
{
        char *s = "Hello, world!"; 
        s[0] = 'T';
        return 0;
}

위의 코드를 다음과 같이 b1, b2로 만듭니다. 옵션은 -fwritable-strings 입니다.

$ gcc -o b1 b.c
$ gcc -o b2 b.c -fwritable-strings

그리고, 각각의 section중에 data 영역을 dump 해보면... b2에는 존재하지만, b1에는 존재하지 않습니다.

$ objdump -s -j .data b1

b1:     file format elf32-i386

Contents of section .data:
 80494c8 00000000 00000000 e8940408 00000000  ................
$ objdump -s -j .data b2

b2:     file format elf32-i386

Contents of section .data:
 80494b8 00000000 00000000 e8940408 00000000  ................
 80494c8 48656c6c 6f2c2077 6f726c64 21000000  Hello, world!...

readonly data 영역을 dump 해보면, b1에 만 존재합니다.

$ objdump -s -j .rodata b1

b1:     file format elf32-i386

Contents of section .rodata:
 80484b0 03000000 01000200 48656c6c 6f2c2077  ........Hello, w
 80484c0 6f726c64 2100                        orld!.          
$ objdump -s -j .rodata b2

b2:     file format elf32-i386

Contents of section .rodata:
 80484b0 03000000 01000200                    ........        

info objdump

~~

즐거운 메모리 해킹되시길.. 바랍니다..

맞습니다. 메모리에 적재되고 적당한 재배치를 한 주소값입니다.

static 과 상관없이 함수는 code (text) segment에 변수는 data,bss segment에 잡힙니다.

여기에서 변수는 자동변수를 제외한 전역변수와 함수내 static 변수를 따졌을때,

이 함수가 export 되느냐 안되느냐에 따라 다른 모듈과 링크될것인지 말것인지를 나타낼뿐입니다.

Windows를 사용하신다면, DUMPBIN을 사용해보세요.

로컬변수의 경우엔 4씩 줄어들었습니다.
3개의 int 지역변수를 선언했을때
스택의 높은 번지에서부터 입력되기때문에
하나씩 들어가면.... 주소는 작아집니다.
data1 | ffff
data2 | .
data3 | .
____ | .
____ | 0

(함수밖의 지역변수는 없는것 같은데) 지역변수는 스택에 들어갑니다.

추가적으로 한마디하자면 코드세그먼트에서 스택에 접근할때는
esp의 상대 위치로 (물론 계산결과는 스택번지겠죠) 이용합니다.

보니까 기계에 의존적인 부분이 많네요

위의 질문하신 내용은 , 기계마다 차이를 가질수 있는 내용이므로

중요한게 아닌거 같습니다

추상적으로 이해하고 있는부분을 컴파일러가 어떻게 구현했냐는 차이겠죠

주소가 올라가서 혹은 내려가서 스택에 할당됐냐? 절대 아닙니다

기계마다 컴파일러마다 방법이 다 틀립니다

그리고 힙 메모리는 윈도우 일 경우 잘 기억은 나지 않지만

프로세스에 디폴트로 1메가를 잡습니다

하지만 1메가보다 커질 경우 OS가 자동으로 힙 크기를 늘려주는 작업을하게

됩니다 , 그냥 할당했을때 보다 시간이 좀더 걸리겠죠

참고로 유닉스의 내부라는 책의 커널 메모리 부분을 보시면

힙 메모리를 어떻게 관리하는지 보실수 있습니다

예를 들면 31바이트 메모리 할당을 요청하면 2의 멱수 단위로

끊어 놓은 리스트들을 돌며 ,31바이트와 제일 비슷한 32 바이트메모리를 가져올수있는지 리스트를 체크합니다

있으면 그 리스트에서 메모리를 가져다가 할당해 줍니다
[없으면 64바이트에서 비었는지 확인하고 가져 오는 방식]

한마디로 기계에 종속되거나 컴파일러에게 종속된 부분 보단

추상화된 개념을 정확히 이해하는게 중요하지 않을까 싶네요?

저는 솔직히 실력이 많이 부족합니다.

이곳의 실력있는 분들께는 항상 고개가 숙여지죠.

이 주제에 대한 글들을 읽으며, 추상적인 이해가 중요하다는데에는 공감합니다만 사실 학습은 일반적인 이론에서부터 구체적인 실용으로 접근하는 것(흔히 하향식 접근(top-down approach)이라 하죠 )으로만으로는 불가능합니다.

물론 다들 아시는 소리지만 또한 구체적 실례학습에 대한 지지가 부족한 느낌이라 조금 딴지를 거는 건데요...

사실 표준이라는 것도 기술이 태동되고, 이것이 다양한 platform 에 적용되면서 그 필요성이 요구되고, 만들어집니다. 표준은 다양한 구체적 기술들을 감안하면서 일반화시키고, 앞으로의 기술들을 거시적 시점에서 좋은 방향으로 이끄는 것일겁니다.

이미 C, C++ 가 대중적이고, 표준이 확립된 시점에서 실력자들이 표준과 일반적 이론을 중시하는 것은 당연하지만 초보자들에게 그러한 것을 들이대면 도무지 감이 안 잡히는 것이죠.

여기에 있는 실력있는 분들도 게시하는 글을 보면 많은 예를 익히고, 시행착오를 거친 이후에 표준과 일반적 이론을 나름대로 통찰했을 거라고 봅니다.

윈도우에서는 스텍을 디폴트로 1M를 잡습니다 [ 처음부터 다 잡는건 아니고
확정은 약 8k정도 하고 예약으로 1M가 잡는것입니다]

여기서 한번에 스텍에 1M가 훨씬 넘는 메모리를 할당한다면

바로 스텍오버 플로어가 나버리죠

하지만 1M선쯤에서 약 몇k 정도 메모리는 무슨 -_-; 상태를 걸어둡니다

따라서 스택에 1M가 조금 넘는 ? k 정도의 메모리에 접근을 하면

메모리 예외 상황이 발생하면서 윈도우가 스텍크기를 배로 늘려주는

작업을 해주게 됩니다

참고로 스택 크기나 힙 크기는 컴파일러에서 처음부터 조절이 가능합니다