깜장 블로그

C++상에서 발생하는 name mangling에 관한 내용

1. name mangling 이란?
간단히 말하면 compiler 가 임의로 함수나 변수의 이름을 변경하는 것을 의미합니다.
그렇다면 왜 함수나 변수의 이름을 변경하는 것인가?
이를 설명하기 위해서는  C++언어의 성격상 function overloading을 먼저 설명해야 하는데요.

function overloading이란 개발자가 소스코드를 작성할때 같은 이름으로 다른 기능들을 수행하는 함수를 만들수 있도록 하는 기능을 예기합니다..
예를 들면,

int Add( int a,int b){return a+b;}
float Add( float a,float b){return a+b;}
float Add( float a,float b, float c){return a+b+c;}

위와 같이 Add라는 함수를 int형을 더하는 함수, float 형을 더하는 함수, 세 변수를 더하는 함수등등 여러개의 함수를 작성하고, 개발자가 이를 임의로 아무거나 불러 쓸 수 있습니다.


이런것이 가능하도록 해주는 기능이 바로 함수 overloading이라는 개념입니다..

그럼 compiler는 소스 코드에서 Add를 호출 했을때 어떻게 각각의 Add를 알아서 찾는가 하는 의문이 생길수 있을것인데,  이를 가능하게 해주는것이 name mangling 이다.

compiler는 symbol을 생성할때 함수 이름과 함수 parameter를 고려 하여 symbol을 만듭니다..
즉,
int Add( int a,int b)  -> Add + int+ int --> Addii 와 같은 형식으로 만든다는 것입니다..
물론, compiler 마다 다른 mangling 규칙을 가지고 있습니다..

인터넷에 떠도는 문서들을 찾다보니 아주 한눈에 잘 들어오도록 정리된 표가 있어서 샤샥!! 퍼옴...

Compiler	void h(int)	void h(int, char)	void h(void)
Intel C++ 8.0 for Linux	_Z1hi	_Z1hic	_Z1hv
HP aC++ A.05.55 IA-64	_Z1hi	_Z1hic	_Z1hv
GNU GCC 3.x and 4.x	_Z1hi	_Z1hic	_Z1hv
HP aC++ A.03.45 PA-RISC	h__Fi	h__Fic	h__Fv
GNU GCC 2.9x	h__Fi	h__Fic	h__Fv
Microsoft VC++ v6/v7	?h@@YAXH@Z	?h@@YAXHD@Z	?h@@YAXXZ
Digital Mars C++	?h@@YAXH@Z	?h@@YAXHD@Z	?h@@YAXXZ
Borland C++ v3.1	@h$qi	@h$qizc	@h$qv
OpenVMS C++ V6.5 (ARM mode)	H__XI	H__XIC	H__XV
OpenVMS C++ V6.5 (ANSI mode)	CXX$__7H__FI0ARG51T	CXX$__7H__FIC26CDH77	CXX$__7H__FV2CB06E8
OpenVMS C++ X7.1 IA-64	CXX$_Z1HI2DSQ26A	CXX$_Z1HIC2NP3LI4	CXX$_Z1HV0BCA19V
SunPro CC	__1cBh6Fi_v_	__1cBh6Fic_v_	__1cBh6F_v_
Tru64 C++ V6.5 (ARM mode)	h__Xi	h__Xic	h__Xv
Tru64 C++ V6.5 (ANSI mode)	__7h__Fi	__7h__Fic	__7h__Fv
Watcom C++ 10.6	W?h$n(i)v	W?h$n(ia)v	W?h$n()v

위와 같이 컴파일러 마다 다른 mangling 규칙을 가지고 있답니다..

자 그럼 C에 대한 이야기도 해야 하는데, C의 경우는 mangled 된 함수 이름이 필요 없습니다.
이유는 C에서는 function overloading을 지원하지 않기 때문에 한 binary안에서는 하나의 function만 존재 합니다.
하지만 !!!  실제로 compile을 해보면 각 함수 이름을 살짝 바꿔 놓기는 합니다. 예를 들면,

void Add(int a,int b) ---> _Add 라는 형식 으로 앞에 '_'를 붙이는 경우부터 해서... 이것 역시 compiler가 각자 규칙을 가지고 진행 합니다.

이런 mangled name 을 확인 해보는 방법은 compile 된 object file(xxx.o) 나 실행 화일 또는 .lib 파일을 hex editor로 열어서 확인 해보면 눈으로 볼 수 있답니다.


2. extern "C" ?
자 , 사실 name mangling 이 발생한다는 것이 개발자가 알고 있어야 하는 지식이기는 하나 그렇다고 mangled 된 이름 가지고 뭘 어떻게 하라는 예기가 사실 그다지 중요하지 않다.
이글의 본 취지는 사실 extern "C" 에 있다.

저도 개발 초기에는 막연하게 "extern "C"를 붙이면 함수의 이름이 C 처럼 나오기 때문에 C++로 짜여진 함수도 C에서 사용할 수 있다." 라고만 알고 있었습니다.

이런 저런 개발을 하다보니 정확한 용법이나 메카니즘을 이해하지 않고 막연하게 사용하는 코드들이나 개념들은 결국 부매랑이 되어 저에게 돌아오더군요.!!
무슨 말이냐 하면,C++에서 짠 함수가 C에서도 사용할수 있게 하려면  extern "C" 를 붙이라는데 어디다? 어떻게 ? 라는 의문이 생겨날 것입니다.
근데 extern "C"에 대해 잘 모르는 사람이 위와 같은 조언을 들었으면,, 분명 extern "C"를 남발하게 됩니다.!!  이는 결국 나중에 compile error를 양산하기도 하고, 코드를 지저분하게 만들기도 하고, 아무튼 문제를 많이 일으키게 되죠.!!! 그런적 없다구요? 전 당했습니다.!! 


자 그럼 하나 하나 차근 차근 짚어 보겠습니다.


extern "C"  --> 이 형식은 extern "C" 이후에 오는 내용을 name mangling 하지 않고 C처럼 symbol을 만들 어라 라는 명령어입니다.

즉, abc.cpp 라는 소스코드에서 아래 abc라는 함수와 def라는 함수를 예로 들어보면,
def는 ii 같은 것이 추가되지 않고 그냥 def라는 이름을 갖게 됩니다.

그러면, 모든 함수 구현 루틴에 extern "C" 를 붙이는것이 사실 귀찮고 힘든 일입니다.
그래서 , 연륜이 있는 개발자들은(저처럼 ㅋㅋㅋ)  extern "C" {}를 활용하게 되는 것이죠. 이렇게 extern "C" {}를 사용하면 {} 안에 있는 모든 내용은 name을 mangling하지 않는 다는 선언이 됩니다.

이렇게 사용하면 모든 함수들을 따라다니면서 extern "C" 를 붙일 필요가 없어지는 것입니다.


또, 다른 형식으로 사용하는 case가 Header file extern "C"를 사용하는 경우가 있습니다.
(대단히 많이 사용하는 형식입니다. 이유는 관리하기가 편해서? ) 자!! 이제 위와 같은 포멧으로 주로 많이들 사용하는데, 위의 내용을 보면 어떤가요? 문제가 있어보이나요 없어보이나요?

얼핏 보기엔 아무런 문제가 없어 보입니다.
하지만!!!!!

한가지 찾아낸 분이 있군요.... 그렇숩니다. ^^a 위의 해더파일은 C 파일에서는 include 해서 사용할 수 없습니다.

이유는 extern "C" 는 C++ compiler에서만 지원하기 때문입니다.
a.c 에서 #include "abc.h"를  사용하면 error가 발생합니다. 
그래서 #ifdef __cplusplus 를 이용해서 extern "C" 를 묶어서 사용합니다. 
이렇게 사용함으로 해서 C compiler에서는 extern "C"를 사용하지 않고 compile됩니다.
C compiler에서는 c니까 당연히 name mangling이 발생하지 않겠죠.!!!! <-- 요거 중요한 예기...


자 그럼 두번째 문제점은 어디에 있을까요??
못찾겠죠... 흔히들 실수 할 수 있는 부분입니다. ( 찾았다구요?? 이 글 왜 읽고 있습니까?? 자리로 돌아가서 일하세요.. ㅎㅎ 다 아시는 분이.. ~~)

두번째 문제는 사실 편하게 쓰고자 extern "C" {} 를 사용하는데 이게 아래와 같이 사용하면 문제를 만듭니다. 무슨 말이냐 하면.. extern "C" {} 중간에 header file을 포함하고 있죠??

*** commands commence before first target. Stop 와 같은 에러가 발생하는 경우

\ 문자 뒤에 공백이 들어가서 그렇다.

Ex ) MOD :=  \

Window > Preferences 에 들어가서, General > Editors > Text Editors 에서 Show line numbers 를 체크해주면 된다.

이 에러의 경우, 해당 class 를 생성( new ) 하는 부분에서 뜬다.

해당 클래스의 부모 클래스를 보면, 순수가상함수가 있을 텐데, 이를 구현하지 않았을 경우

이러한 메세지를 띄워준다. 순수가상함수는 객체 전체의 메모리의 일부분을 차지하게 되고, 이를

컴파일러에서는 생각하고 있을 텐데, 이를 자식이 구현을 하지 않았을 경우에는, 해당 부분이 없으

므로, 메모리를 할당해야되는 부분을 구현하지 않았으므로, 추상타입의 객체를 할당 할 수 없다고 나

오는 것이다.

1) GET  : URL로 자원 또는 파일을 달라고(get) 요청함

2) POST : Request 에 첨부한 몸체정보를 서버로 보내어, 요청한 URL 로 이 정보를 넘겨주라고 요청함. 용량이 큰 GET, 부가정보를 가진 GET

3) HEAD : GET이 무엇을 리턴하든 간에 헤더 정보만 요청함.
               이는 Response 의 몸체 정보가 없다는 것만 삐면 GET 과 동일함.
               요청한 URL 로부터 요청한 정보는 빼고 헤더 정보만 가져오는 것임.

4) TRACE : 요청한 메시지의 루프백(loopvack) 테스트를 요청함. 
                 서버로부터 받은 내용을 클라이언트 쪽에서 확인하기 위해 사용.
                 테스트 목적 또는 문제 해결을 위해 사용함

5) PUT : 동봉한 몸체 정보를 요청한 URL 로 올리기 위해 사용함.

6) DELETE : 요청한 URL에 있는 자원이나 파일을 삭제하기 위해 사용함.

7) OPTION : 요청한 URL이 응답할 수 있는 HTTP 메소드가 무엇인지 요청함.

8) CONNECT : 터널링의 목적으로 연결을 요청함.

invoke : 호출하다.

세마포어는 병렬 프로그래밍 환경에서 공동 리소스에 여러 프로세스들에 의한 엑세스를 제어하는 전통적인 방법이다. 세마포어는 바이너리와 카운팅의 두가지 형태를 일반적으로 취한다. 바이너리 세마포어는 간단히 "true/false"(locked/unlocked) 플래그이며, 하나의 리소스를 접근하는 것을 제어한다. 카운팅 세마포어는 여러 리소스를 위한 카운터이다. 각 세마포어 타입은 race condition 을 방지하기 위해 사용된다. ( race condition : 프로세스의 결과가 여러 이벤트의 타이밍이나 순서에 예상치 못하게 그리고 심각하게 의존하고 있을 때, 프로세스의 결점이나 문제를 말한다. 멀티 쓰레드 환경에서나 분산 프로그램에서 발생할 수 있다. 출처 : http://en.wikipedia.org/wiki/Race_conditions )
반면에, 세마포어는 리소스 데드락을 방지하는데는 아무런 의미가 없다. ( 예 : 식사하는 철학자 문제 )

Binary semaphore vs. Mutex vs. Event
: 뮤텍스 는 바이너리 세마포어로, 보통 소유권, 우선순위 역전( prioirty inversion ) 방지나 반복과 같은 추가의 특징을 포함한다. 뮤텍스가 특별하고, 더 빠른 루틴에 의해 실행되더라도, 뮤텍스와 세마포어의 차이점은 운영체제 의존도 이다. 뮤텍스는 상호배제에 사용되고, 바이너리 세마포어는 이벤트 알림에 사용되도록 의도된다.
정리하자면, 뮤텍스란, 상호배제로 크리티컬 섹션에 여러 Thread 가 동시에 접근하지 못하고 순차적으로 접근을 할 수 있도록 보장해주는 것을 뜻한다.( 공유 불가능한 자원의 동시 사용을 피함 ) 한 Thread 에서 크리티컬 섹션에서 진행 중일 때 다른 Thread 는 이를 기다렸다가, 크리티컬 섹션에서 작업 중인 Thread 가 크리티컬 섹션에서 벗어나면 기다리던 Thread가 순차적으로 진입을 하게 된다.
세마포어는, 데드락을 피하기 위한 기술로, 멀티프로그래밍 환경에서 공유 자원에 대한 접근을 제한하는 방법으로 사용된다.

어떻게 보면 두개는 비슷한 것 같다. 명확히 차이를 말 못하겠다.. -_-; 어쿠.. 다음 기회에..ㅎ

출처 : http://en.wikipedia.org/wiki/Semaphore_(programming)

Event-driven programming 또는 event-based programming은 프로그래밍 방법론 중에 하나로써, 프로그램의 흐름이 이벤트에 의해 결정이 된다. 다른 프로그램이나 쓰레드의 메시지나 사용자 행동이나 센서의 출력과 같은 이벤트가 있다.
어플리케이션이 이벤트를 선택 또는 이벤트를 감지하고, 이벤트를 처리하는 분명한 두 섹션을 가지는 어플리케이션 아키텍쳐 기술로 정의가 될 수도 있다.

Contrast with batch programming
: 배치 프로그램에서, 프로그램의 흐름은 프로그래머의 의해 결정이 된다. 배치 프로그래밍이 초보 프로그래밍 수업에서 가르치는 스타일 이라고 하더라도, 더 복잡한 event-driven programming 은 현대 대화형 프로그램의 표준 아키텍쳐이다.

출처 : http://en.wikipedia.org/wiki/Event-driven_programming

event-driven 방식은 윈도우에서 뿐만 아니라 네트워크 통신 등 다양한 분야에서 많이 사용하고 있으며, 이 방식을 사용하게 되면 framework 에 좀 더 빨리 return 을 해줄 수 있게 되어, framework 에서 더 많은 처리를 할 수 있도록 어플리케이션에서 대응을 해줄 수 있다.

Post/Redirect/Get( PRG ) 는 웹 개발자들이 특정 중복되는 폼을 요청하는 것을 피하도록 돕고, user agent 가 bookmarks, refresh 버튼을 좀더 더 직관적으로 사용할 수 있도록 해주는 흔한 디자인 패턴이다.
( user agent : 분산 컴퓨팅 시스템의 통신에서 사용되는 네트워크 프로토콜을 사용하는 클라이언트 프로그램을 말하고, 이 용어는 주로 World Wide Web 을 엑세스 하는 어플리케이션을 말한다. SIP( Session Initiation Protocol )와 같은 다른 시스템에서는 user agent 라는 용어를 통신 세션의 양 끝을 의미할 때 사용한다.
 출처 : http://en.wikipedia.org/wiki/User_agent )
HTTP POST 요청을 통해 서버에 웹 폼이 전달될 때, 특정 user agents에서 서버 응답을 재요청하려고 하는 웹 사용자는 original HTTP POST 요청 내용을 재요청할 수있고, 중복 웹 구매와 같은 원하지 않았던 결과를 야기할 수 있다. 이 문제를 피하기 위해 많은 웹 개발자 들이 웹페이지를 직접적으로 보내주는 대신에, POST operation이 redirection 명령어를 return 하는, PRG 패턴을 사용하고 있다.( redirection command : HTTP "Location" response header 를 함께 사용하여 HTTP 303 응답 코드 ( 가끔씩 HTTP 302 ) 를 사용하며, 브라우저에게 GTTP GET 요청을 사용하여 다른 페이지를 로드 하라는 명령을 한다 ) 그래서, 웹 사용자는 초기 HTTP POST 요청을 재전송하지않고, 서버 응답을 안전하게 재요청한다.
쉽게 설명을 하자면, 아래 두 그림을 보면 명확하게 알 수 있다.