실행파일이 OS 의 memory loader ( ML ) 에 의해 해독되어 램에 올라가면 실행파일보다 조금 커진다.
실행파일( Windows 에서는 PE, Linux 등에선 ELF 포맷 같은 )이란게
헤더-환경변수-실행코드-초기화해줄 데이타들 정도로 구성되는데,
실행파일이 메모리에 올라가 실행을 시작하면 그게 process 라고 불리우는 것이지.
메모리에 올라가면 static data 영역, heap, dynamic data 영역( stack ) 이 추가되니까
당연히 실행파일보다 크기가 커지는 것.
process를 지도로 그려보면 대략
[ code ][ literal ][ static data ][ heap ][ stack data ]
순서로 배치된다. OS 마다 약간은 다름. 컴파일러 마다도 data 영역은 다를 수 있음.
여기서 대부분의 컴파일러들은 literal 영역을 읽기 전용으로 만든다.
그래서,
char* str = "hello world";
strcpy( str, "hell " );
하면 hell world 가 찍힐것 같지만 대부분은 그렇게 되지 않지.
프로그램에서 사용된 상수라는게, primitive 타입의 상수 ( 정수형 같은 ) 들이 있고,
수열이나 문자열이나 사용자 타입처럼 확장된 상수들이 있을 수 있는데,
[ code ]내에 삽입될 수 있는 것들은 대개 primitive 타입들이다.
mov EAX, 5
에서 5 같은 녀석들이지
만약 연속한 수열이나 문자열을( 문자열도 곧 수열이다. C 에선 마지막에 0 이 오는게 약속되어 있을 뿐 )
담아야 한다면 코드 내에 들어갈 수가 없지.
만약 어디까지가 코드인지 어디까지가 데이타인지 일일이 분기해야 한다면 비효율적이지.
그래서 확장 데이타들은 리터럴 영역에 보관하게 되는 것.
실행파일을 열어보면 문자열 상수 같은것들을 실행파일 뒷부분에서 찾아볼 수 있는 것도 그런 이치.
( 사실 메모리에 올라가는 순서를 거의 그대로 압축해놓은것이 실행파일이기 때문 )
p.s. 세상 모든것은 큰~수열이다.
가끔 프로세서 특성상 멀리있는 리터럴 참조가 번거로워서 코드영역에 놓는경우도 있더라 risc류 특히
오홍 - dc App
premitive -> primitive
결론은 5같은 상수는 code에 "hello"같은 문자열 상수는 literal 에 저장된 다는 거죠? - dc App
오키 오타 수정할께 땡큐
preemption 치다 와서 손가락이 ㅋㅋ
나이들수록 오타랑 친해지는것.
@SME 응 쉽게 말하면 그럼.
goes 가 말했듯, 캐시효율이나 보안상의 문제를 위해서 리터럴 페이지를 여러개 운용하는 애들도 있음.
형 글만 읽고 있어도 책 안봐도 되것다.. ㅎㄷㄷ
예가 잘못됐네 hello world 가 나오는게 대부분이고 리터럴 쓰기가 되는 특정 컴파일러에선 hell 이 찍히겠지 급히쓰다 실수 함