« Previous : 1 : ... 6 : 7 : 8 : 9 : 10 : 11 : 12 : 13 : 14 : ... 33 : Next »

2.링크와 로더

2008/01/07 10:35 / Resource

1. 서문

링킹(linking)은 여러가지 코드와 데이터를 묶어 메모리로 로드될 수 있는 하나의 실행가능한 파일을 만드는 작업이다. 링킹은 컴파일-타임때 행해질 수도 있고, 로드-타임(로더에 의해), 혹은 런-타임(응용 프로그램에 의해)때도 행해질 수 있다. 1940년대에는 이러한 링킹작업을 사람이 손수 하였다. 현재에는 공유 라이브러리(shared library)들을 동적으로 링킹시켜주는 등의 복잡한 일을 할 수 있는 링커(linker)라는 것이 있다. 이 문서는 링킹의 모든 과정, 예로 들자면 재배치(relocation)와 심볼 해석(symbol resolution)부터 위치 독립적(position independent)인 공유 라이브러리 지원등에 대해 다룬다.문제를 간단하고 이해하기 쉽게 하기위해, 나는 이 문서를 x86 아키텍처에 기반한 리눅스와 GNU 컴파일러(GCC)와 링커(ld)에 기반한 ELF(executable and linking format) 실행파일에 초점을 맞추었다. 그러나, 기본적인 링킹의 아이디어는 운영체제, 프로세서 또는 오브젝트 파일의 형식에 무관하게 적용될 수 있다.


1.1. 저작권 정보

이 문서는 2002년 11월 26일, Linux Journal에 Sandeep Grover씨가 Linkers and Loaders라는 제목으로 기재하신 글입니다. 원 저자에게 메일로 연락하여 실렸던 잡지의 이름과 원저자가 누군지를 밝히면 번역을 해도 좋다는 동의를 얻었습니다.


1.2. 피드백

이 문서에 대한 발전적인 제안이나 수정사항, 문제점 등에 대한 피드백은 언제든지 환영합니다. 메일을 보내 주십시오.


2. 컴파일러, 링커, 로더들의 동작: 기본 사항

a.c와 b.c 두 개의 프로그램이 있다고 가정하고, 쉘 프롬프트에서 a.c와 b.c를 gcc를 이용하여 아래와 같은 명령을 수행하면 다음과 같은 일들이 순서대로 수행된다.

gcc a.c b.c

  • a.c에 대하여 전처리기(preprocessor)를 수행시키고, 그 결과를 전처리된 임시파일에 저장한다.

    cpp [other-command-line options] a.c /tmp/a.i

  • a.i에 대하여 컴파일러를 수행시키고, a.s라는 어셈블러 코드를 생성한다.

    cc1 [other-command-line options] /tmp/a.i -o /tmp/a.s

  • a.s에 대하여 어셈블러를 수행시키고, a.o라는 오브젝트 파일을 생성한다.

    as [other-command-line options] /tmp/a.s -o /tmp/a.o

cpp, cc1, as는 GNU의 전처리기, 컴파일러, 어셈블러를 각각 나타내며, GCC 배포본 안에 들어있다.

위와 같은 스텝은 b.c에도 똑같이 적용되어 b.o라는 오브젝트 파일을 하나 더 생성하게 된다. 그러면 링커의 작업은 이러한 두 개의 오브젝트 파일들(a.o, b.o)을 입력으로 받아서 최종적으로 실행가능한 파일을 만드는 것이다.

ld [other-command-line options] /tmp/a.o /tmp/b.o -o a.out

최종적으로 만들어진 실행파일(a.out)은 이제 로드될 준비가 되었다. 이것을 실행시키기 위해서 우리는 쉘 프롬프트상에서 아래와 같이 타이핑한다.

./a.out

그러면 쉘은 로더를 불러 a.out의 코드와 데이터를 메모리로 복사하고, 프로그램내의 제일 처음으로 제어권을 넘긴다. 여기서 말하는 로더는 execve라는 것으로 실행가능한 오브젝트 파일의 코드와 데이터를 메모리로 로드하고 그 프로그램의 첫번째 명령어가 저장된 주소로 점프함으로써 프로그램을 수행하게 한다.

a.out이라는 명칭은 a.out 오브젝트 파일들안에 있는 어셈블러의 출력물에서 그 유래를 찾을 수 있다. 그 이후로 오브젝트 형식은 다양하게 바뀌어 왔지만, 그 이름은 계속 사용되어지고 있다.


3. 링커와 로더

링커와 로더는 많은 부분이 연관되어 수행되지만 개념적으로는 다른 작업들을 수행한다.

  • 프로그램 로딩(Program Loading). 이것은 프로그램을 실행가능한 상태로 만들기 위해 하드 디스크로부터 프로그램 이미지를 읽어서 메인 메모리로 복사하는 것을 말한다. 어떤 경우에는 프로그램 로딩이 저장(storage)공간을 할당하거나 가상주소를 디스크 페이지로 매핑하는 일도 한다.

  • 재배치(Relocation). 컴파일러와 어셈블러는 각각의 입력 파일들로부터 시작주소가 제로인 오브젝트 코드를 생성한다. 재배치라는 것은 프로그램의 각기 다른 부분들(코드와 데이터)에 대해 로드되는 주소를 할당하는 것이다. 이러한 작업은 같은 타입(코드 혹은 데이터)으로 정의된 모든 구간들을 하나의 구간으로 합치고, 이러한 구간들이 런-타임때 올바른 주소를 가리킬 수 있도록 조정하는 것을 말한다.

  • 심볼 해석(Symbol Resolution). 프로그램은 다양한 하위 프로그램(subprogram)들로 구성된다; 하나의 상위 프로그램이 다른 하위 프로그램을 참조하는 것은 심볼이라는 것을 통해 이루어진다. 링커의 작업은 이러한 심볼의 위치를 알아내어 상위 프로그램의 오브젝트 코드에 하위 프로그램의 주소를 기입하여 참조를 해석하도록 한다.

링커와 로더사이에는 중첩되는 일들과 각각 차이나는 일들도 있는데, 이렇게 생각하도록 하자: 로더는 프로그램이 로딩되도록 하며; 링커는 심볼을 해석하며; 링커와 로더, 둘 다 재배치를 할 수 있다.


4. 오브젝트 파일들

오브젝트 파일들은 세가지로 분류될 수 있다.

  • 재배치 가능한 오브젝트 파일(Relocatable object file). 이것은 바이너리 코드와 데이터를 가지고 있으며, 실행가능한 오브젝트 파일을 만들기 위해 컴파일-타임때 재배치 가능한 다른 오브젝트 파일들과 결합될 수 있는 것을 가리킨다.

  • 실행가능한 오브젝트 파일(Executable object file). 이것은 바이너리 코드와 데이터를 가지고 있으며, 메모리로 직접 로드되어 실행될 수 있는 것을 가리킨다.

  • 공유 오브젝트 파일(Shared object file). 이것은 재배치 가능한 오브젝트 파일의 특별한 타입으로, 로드-타임이나 런-타임때 동적으로 메모리로 로드되고 링킹될 수 있는 것을 가리킨다.

컴파일러와 어셈블러는 재배치 가능한 오브젝트 파일을 생성한다(공유 오브젝트 파일도 또한 생성한다). 링커는 이러한 오브젝트 파일들을 합쳐 실행가능한 오브젝트 파일들을 생성한다.

오브젝트 파일들은 시스템에 따라 그 형식이 다르다. 최초의 유닉스 시스템은 a.out 포맷을 사용하였다. System V의 초기 버전에서는 COFF(Common object file format)라는 것을 사용하였고, 윈도우즈 NT는 COFF의 변형인 PE(portable executable)라는 형식을 사용한다; IBM은 독자적인 IBM 360 형식을 사용한다. 리눅스와 솔라리스와 같은 현대적인 유닉스 시스템들은 유닉스 ELF(executable and linking format)포맷을 사용한다. 이 문서는 주로 ELF에 대해 다룬다.

표 1. 전형적인 재배치 가능한 ELF 오브젝트 파일의 형식

ELF Header
.text
.rodata
.data
.bss
.symtab
.rel.text
.rel.data
.debug
.line
.strtab

ELF 헤더는 4-byte magic문자열(177ELF)로 시작한다. ELF 재배치 가능한 오브젝트 파일의 각 구간의 의미는 아래와 같다.

  • .text, 컴파일된 코드의 머신 코드가 들어있다.

  • .rodata, read-only 데이터가 들어있다, printf문의 문자열등이 이에 해당한다.

  • .data, 초기화된 전역 변수들이 들어있다.

  • .bss, 초기화되지 않은 전역 변수들이 들어있다. BSS는 block storage start의 이니셜이고, 이 구간은 실제적으로 오브젝트 파일에서 공간을 차지하지 않고 단지 공간을 확보하는 역할만 한다.

  • .symtab, 프로그램에서 정의된 전역 변수들과 함수들에 대한 참조 정보를 가지고 있다. 이 테이블은 지역 변수에 대한 것은 담고 있지 않다; 지역 변수들은 스택에 의해 유지된다.

  • .rel.text, .text에 들어있는 각 머신 코드의 위치를 나타낸다. 이것들은 나중에 링커가 이 오브젝트 파일을 다른 오브젝트 파일들과 연결시킬때 필요하다.

  • .rel.data, 현재의 파일에서는 정의되어 있지 않지만 참조되는 전역 변수에 대한 재배치 정보를 담고 있다.

  • .debug, 지역, 전역 변수들에 대한 디버깅 심볼들이 들어있다. 이 구간은 컴파일러가 -g 옵션과 함께 수행될 때 생성된다.

  • .line, .text에 들어있는 머신 코드와 실제 C 코드의 라인 넘버에 대한 메핑 정보가 들어있다. 디버거 프로그램이 이 정보를 필요로 한다.

  • .strtab, .symtab, .debug 구간에 있는 심볼 테이블에 들어있는 스트링들에 대한 테이블이다.


5. 심볼들과 심볼 해석

모든 재배치 가능한 오브젝트 파일들은 심볼 테이블과 그와 관련된 심볼들을 가지고 있다. 링커의 관점에서 볼 때 심볼들을 다음과 같이 분류할 수 있다.

  • 현재의 파일에서 정의되고, 다른 파일들에서 참조되는 전역 심볼. 모든 non-static 함수들과 전역 변수들이 이 분류에 해당한다.

  • 현재의 파일에서 참조는 되나, 다른 곳에서 정의된 전역 심볼. extern으로 정의된 모든 함수들과 변수들이 이 분류에 해당한다.

  • 현재의 파일에서만 정의되고 참조되는 지역 심볼. 모든 static 함수들과 변수들이 이 분류에 해당한다.

링커는 심볼의 참조를 해석할 때, 입력으로 주어지는 재배치 가능한 오브젝트 파일의 심볼 테이블로부터 꼭 하나만 존재하는 심볼의 정의를 참조하여 심볼 참조를 해석한다. 지역 심볼(local symbol)은 그에 대한 다중 정의(multiple definitions)를 심볼 테이블이 가질 수 없으므로 쉽게 해석된다. 그러나 전역 심볼의 해석은 약간의 트릭이 요구된다. 컴파일 타임때, 컴파일러는 전역 심볼들을 strong 혹은 weak한 것으로 만드는데, 함수들과 초기화된 전역 변수들은 strong하게, 초기화되지 않은 변수들은 weak하게 만든다. 그러면 링커는 아래의 룰을 적용하여 심볼들을 해석하게 된다.

  1. 다중 strong 심볼들은 허가되지 않는다.

  2. 하나의 strong 심볼과 여러개의 weak 심볼들이 있으면, strong 심볼을 선택한다.

  3. 여러개의 weak 심볼들이 있으면, 그것들중 아무거나 선택한다.

예로, 다음과 같은 두 프로그램의 링킹은 링크-타임 에러를 낸다.

/* foo.c */

int foo() {
	return 0;
}
/* bar.c */

int foo() {
	return 1;
}

int main() {
	foo();
}

foo (전역 함수로써 strong 심볼이다)가 두 번 정의 되었으므로, 링커는 아래와 같은 에러 메세지를 낸다.

gcc foo.c bar.c

/tmp/ccM1DKre.o: In function 'foo':

/tmp/ccM1DKre.o(.text+0x0): multiple definition of 'foo'

/tmp/ccIhvEMn.o(.text+0x0): first defined here

collect2: ld returned 1 exit status

collec2는 GCC에 의해 호출되는 링커 ld의 wrapper이다.


6. 정적 라이브러리의 링킹

정적 라이브러리는 비슷한 형을 지닌 오브젝트 파일들의 집합이다. 이러한 라이브러리들은 디스크에 아카이브(archive) 형식으로 저장된다. 아카이브는 라이브러리를 구성하고 있는 것들을 좀 더 빠르게 검색하기 위해 디렉토리 정보를 또한 가지고 있다. 각각의 ELF 아카이브는 !arch\n (\n은 뉴라인을 뜻한다)의 8자로 구성된 magic 문자열로 시작한다.

정적 라이브러리들은 링커에게 인자 (arguments)로써 전달된다. 그러면 링커는 프로그램에서 참조되는 오브젝트 모듈들만을 복사한다. 유닉스 시스템에서 libc.a는 모든 C 라이브러리 함수들 (printf나 fopen등과 같은)을 담고 있다.

gcc foo.o bar.o /usr/lib/libc.a /usr/lib/libm.a

libm.a는 유닉스 시스템에서 sqrt, sin, cos과 같은 수학관련 함수들을 담고 있는 라이브러리이다.

정적 라이브러리를 이용할 때, 심볼 해석과정이 어떻게 이루어지나 보면, 링커는 커맨드 라인에서 입력으로 받은 재배치 가능한 오브젝트 파일들과 아카이브들을 왼쪽에서 오른쪽으로 스캔한다. 이러한 스캔 과정중에, 링커는 세가지의 집합을 유지한다. 먼저, 재배치 가능한 오브젝트 파일들이 실행 가능한 파일의 상태로 들어간 집합 O; 아직 해석되지 않은 심볼들을 담고 있는 집합 U, 이전의 입력 파일에서 정의된 심볼을 담고 있는 집합 D가 그것이다. 이러한 집합들은 초기에 비워진 상태이다.

  • 커맨드 라인의 각각의 입력 파일에 대해, 링커는 그것이 오브젝트 파일인지 아카이브인지를 먼저 결정한다. 만약 입력이 재배치 가능한 오브젝트 파일이면, 링커는 그것을 집합 O에 추가하고, 집합 U와 D를 업데이트한 후, 다음 입력 파일로 넘어간다.

  • 만약 입력 파일이 아카이브라면, 링커는 현재의 집합 U에 들어있는 아직 해석이 안된 심볼들을 해석하기 위해 아카이브를 구성하고 있는 멤버 모듈들을 스캔하여 풀어나간다. 만약 아카이브를 구성하고 있는 멤버 모듈 자체에도 해석이 안된 심볼들이 있으면, 그 멤버는 집합 O에 추가되고 집합 U와 D도 업데이트 된다. 이러한 과정은 아카이브를 구성하고 있는 모든 오브젝트 파일 모듈들에 대해 행해진다.

  • 만약 커맨드 라인에 주어진 모든 입력 파일들에 위의 두 스텝을 행하였는데도, 집합 U가 아직 비어 있지않다면, 링커는 에러 메세지를 내고 종료한다. 집합 U가 비어 있다면, 링커는 집합 O에 들어있는 모든 오브젝트 파일들을 병합하고 재배치시켜 실행가능한 출력 파일을 만들어 낸다.

위의 일련의 순서때문에 커맨드 라인에서 정적 라이브러리가 끝에 온다. 또한 라이브러리들 사이에 발생할 수 있는 순환적인 의존성도 주의깊게 살펴야한다. 입력으로 주어지는 라이브러리들은 순서대로 주어져서 아카이브의 멤버들이 참조할 수 있도록 해야하며, 정의된 하나의 심볼은 뒤따르는 커맨드 라인의 입력에 의해 참조되어야 한다. 만약 해석이 안된 심볼이 있고, 그 심볼이 여러 정적 라이브러리들내에서 정의되어 있으면, 커맨드 라인에서 처음에 주어진 라이브러리에 정의된 것을 받아들인다.


7. 재배치(Relocation)

링커가 모든 심볼을 해석하고 나면, 심볼 참조는 오직 하나의 심볼 정의만을 가지게 된다. 그 때, 링커는 아래 두 스텝으로 구성된 재배치 작업을 하게된다.

  • 섹션과 심볼정의들을 재배치한다. 링커는 같은 타입의 모든 섹션들을 새로운 하나의 섹션으로 통합한다. 예로 들면, 링커는 입력으로 받은 모든 재배치 가능한 오브젝트 파일들의 .data섹션을 합쳐 하나의 .data섹션을 만든다. 같은 과정이 .code에 대해서도 행해진다. 그런 후에 링커는 병합된 새로운 섹션과, 병합된 새로운 섹션내의 각 섹션, 그리고 모든 심볼들에 대해 런-타임 메모리 주소를 할당한다. 이러한 작업후에는 프로그램의 모든 코드와 전역 변수들은 고유한 로드-타임 주소를 가지게 된다.

  • 섹션들안에 있는 심볼의 참조를 재배치한다. 이 과정에서, 링커는 코드와 데이터 섹션에 있는 모든 심볼 참조를 수정하여, 그것들이 올바른 로드-타임 주소를 가지게 한다.

어셈블러가 해석안된 심볼들을 만날 때마다, 어셈블러는 오브젝트 파일의 .rel.text/.rel.data 섹션에 해석안된 심볼들을 위한 재배치 항목을 생성한다. 이러한 재배치 항목은 해석안된 심볼들이 어떻게 해석되어야 하는지에 대한 정보들을 담고 있다. 전형적인 ELF 재배치 항목은 다음과 같은 멤버들로 구성된다.

  • 옵셋, 재배치되어질 필요가 있는 심볼 참조의 섹션내애서의 옵셋을 나타내며, 혹은 디스크의 저장공간이 오브젝트 파일내에서 재배치되어질 필요가 있을 시, 이 값은 재배치될 필요가 있는 디스크 섹션의 처음부터 바이트단위로 얼마만큼 떨어져 있는가를 나타낸다.

  • 심볼, 이것은 심볼 테이블에서의 인덱스로서, 아직 해석이 안된 심볼이 심볼 테이블에서 몇 번째 위치에 있는가를 나타낸다.

  • 타입, 재배치 타입, 일반적으로 R_386_PC32, 이는 PC-relative 주소지정방식을 나타내며, R_386_32는 절대주소지정방식을 나타낸다.

링커는 재배치 가능한 오브젝트 모듈들 안에 있는 모든 재배치 엔트리에 대해 이 작업을 반복하고 그것들의 타입에 따라 해석안된 심볼들을 재배치한다. R_386_PC32는 재배치 주소를 S+A-P로 계산하며, R_386_32는 S+A로 계산한다. 이 계산에서, S는 재배치 항목의 심볼항목에 들어있는 값을 가리키며, P는 섹션 옵셋 혹은 재배치되는 저장장치의 주소를 나타낸다 (재배치 항목의 옵셋값으로부터 계산된다). 그리고 A는 재배치 가능한 필드를 계산하는데 필요한 주소이다.


1. 동적 링킹: 공유 라이브러리

위의 정적 라이브러리는 몇가지 중요한 단점들을 지니고 있다; 예로, printf나 scanf와 같은 함수들을 고려해보자. 이러한 함수들은 거의 모든 응용 프로그램에서 사용된다. 만약 시스템이 50~100개의 프로세스를 동작시키고 있다면, 각 프로세스는 각각 printf와 scanf의 실행 가능한 코드의 복사본을 가지고 동작하게 된다. 이것은 메모리 공간의 중대한 낭비를 초래한다. 공유 라이브러리는 이러한 정적 라이브러리의 단점을 해결한다. 공유 라이브러리는 런-타임때 메모리의 임의의 위치로 로드될 수 있는 오브젝트 모듈이다. 그리고 그것은 메모리에서 프로그램과 링킹될 수 있다. 공유 라이브러리는 종종 공유 오브젝트라고도 불리운다. 대부분의 유닉스 시스템에서는 .so로 공유 라이브러리 파일명이 끝나며; HP-UX에서는 .sl로 끝나고 마이크로 소프트사는 DLL(dynamic link libraries)로 부른다.

공유 오브젝트를 만들기 위해, 컴파일러는 다음과 같은 옵션을 가지고 호출된다.

gcc -shared -fPIC -o libfoo.so a.o b.o

위의 명령어는 컴파일러가 a.o, b.o라는 두 개의 오브젝트 모듈들로부터 libfoo.so라는 공유 라이브러리를 만들도록 한다. -fPIC 옵션은 컴파일러에게 위치 독립적인 코드(position independent code)를 만들도록 한다.

만약 bar.o라는 오브젝트 모듈이 a.o, b.o와 의존성이 존재한다고 가정하면, 링커는 다음처럼 불리워진다.

gcc bar.o ./libfoo.so

이 명령어는 로드-타임때 링크될 수 있는 a.out이라는 실행파일을 만든다. 여기서 a.out은 정적 라이브러리를 사용할 때는 포함되었던 a.o와 b.o 오브젝트 모듈을 포함하고 있지 않다. 이 실행파일은 런-타임때 libfoo.so와 함께 해석될 수 있는 재배치와 심볼 테이블만을 포함하고 있다. 따라서, a.out은 libfoo.so와의 의존성이 존재하는 부분적으로 실행가능한 파일(partially executable file)이다. 이 실행가능한 파일은 .interp라는 섹션을 가지고 있는데, 이 섹션은 동적링커(dynamic linker)의 이름을 가리키고 있다. 동적링커 자체도 리눅스에서는 ld-linux.so라는 공유 오브젝트이다. 그래서 실행파일이 메모리로 적재될 때, 로더는 제어권을 동적링커로 넘긴다. 동적링커는 공유 라이브러리들과 해당 프로그램의 주소공간을 매핑시킬 수 있는 start-up 코드를 가지고 있고 다음과 같이 동작한다.

  • libfoo.so의 코드와 데이터를 메모리 속으로 재배치한다.

  • a.out에 있는 참조들을 libfoo.so에 정의되어 있는 것으로 재배치한다.

마지막으로, 동적링커는 제어권을 응용프로그램으로 넘긴다. 이때부터 공유 오브젝트는 메모리에 고정되게 된다.


2. 응용 프로그램으로부터 동적 라이브러리 로딩

동적 라이브러리들은 응용 프로그램이 실행되고 있는 중에도 로드될 수 있다. 응용 프로그램은 공유 라이브러리들을 자신과 링킹하지 않아도, 동적링커에게 요청하여 공유 라이브러리들을 로드하고 링킹시킬 수 있다. 리눅스와 솔라리스 그리고 다른 시스템들에서는 이를 위해 동적으로 공유 오브젝트들을 로드할 수 있는 몇가지 종류의 함수들을 제공한다. 리눅스에서는 공유 오브젝트를 열 수 있는 dlopen; 공유 오브젝트의 심볼 테이블을 볼 수 있는 dlsym, 공유 오브젝트를 닫을 수 있는 dlclose와 같은 시스템 콜을 제공하며, 윈도우즈에서는 LoadLibrary와 GetProcAddress와 같은 함수들을 제공한다.

오브젝트 파일들을 조작할 수 있는 툴들

여기에 오브젝트 파일들과 실행파일들을 조사할 수 있는 툴들의 목록이 있다.

  • ar: 정적 라이브러리들을 만든다.

  • objdump: 가장 중요한 바이너리 툴; 바이너리 형식 오브젝트 파일의 모든 정보를 보여준다.

  • strings: 바이너리 파일의 출력가능한 모든 문자열들을 보여준다.

  • nm: 오브젝트 파일의 심볼 테이블에 정의된 심볼들의 리스트를 보여준다.

  • ldd: 오브젝트 바이너리 파일이 의존하고 있는 공유 라이브러리들의 목록을 보여준다.

  • strip: 심볼 테이블 정보를 지운다.

크리에이티브 커먼즈 라이센스
Creative Commons License
이올린에 북마크하기
Posted by 소리나는연탄.
TAGS ,

Leave your greetings here.

  
  
  
  
  
  
  
  
 
중국의 기업정책이 크게 변화하고 있다. 이러한 변화는 2002년에 출범한 후진타오(胡錦濤) 지도부가 '시장경제'와 '글로벌스탠더드'를 일관성있게 추진하고 있음을 의미한다. 특히 2007년 가을에 시작되는 후진타오 2기 지도부가 2010년까지 각종 개혁법안의 완성을 목표로 하고 있기 때문에 향후 기업정책의 변화는 더욱 가속될 전망이다.
Ⅰ. 중국의 기업정책 변화 추이

Ⅱ. 기업정책 변화의 내용과 영향

Ⅲ. 시사점 및 대응방안
전문: 중국의 기업정책 변화와 시사점

출처: 삼성경제연구원
크리에이티브 커먼즈 라이센스
Creative Commons License
이올린에 북마크하기
Posted by 소리나는연탄.

Leave your greetings here.

  
  
  
  
  
  
  
  
 

1. 금융지주회사의 의의


□ 금융지주회사란 주식(지분)보유를 통해 금융기관(은행, 비은행-증권,보험 등)을 자회사로 소유하고 경영하는 회사를 의미함


□ 금융지주회사의 형태로는 지주회사 본체가 금융업무를 직접 하는가의 여부에 따라 '純粹지주회사'와 '事業지주회사'로 구분됨


순수지주회사는 사업지주회사와 달리 지주회사 자신이 사업을 하지 않는 일종의 페이퍼컴퍼니(paper company)로서, 현재 국회 상정중인 금융지주회사법안에서는 순수금융지주회사(미국형)를 허용하고 있음
시티그룹을 비롯해 미국의 금융지주회사들이 주로 순수지주회사로 운영되고 있는 반면, 유니버셜뱅킹 형태인 유럽은행들은 금융업무를 영위하면서 자회사를 거느리는 사업지주회사 방식을 취하고 있음


□ 순수금융지주회사는 현재 국내 금융기관이 직접 금융업무(예대업무 등 은행고유업무)를 수행하면서 증권,보험 등의 자회사 방식으로 새로운 사업에 진출하는 업태별 자회사방식('93년에 허용됨)과 차이가 있으며, 한 금융기관의 본체 내에서 은행, 증권, 보험, 자산관리 등 모든 금융업무를 병행하는 인하우스(In-House, 한지붕) 방식의 겸업체제와도 구별됨


- 금융겸업(유니버셜뱅킹)의 유형은 크게 4가지로 상정되는데, 금융지주회사는 그 중 한 형태임
금융겸업은 그 형태에 따라 ①직접겸업 ②자회사 겸업 ③지주회사 겸업 ④제휴 겸업 등으로 구분됨


직접 겸업
동일 법인체가 복수의 업종을 직접 영위
은행의 신탁, 신용카드, 종금 업무 겸업
독일은행의 증권업무 겸업


자회사 방식
이종 금융기관을 자회사로 보유 겸업
은행의 증권자회사 보유
영국형(일본, 한국이 해당)


지주회사 방식
금융지주회사가 복수의 금융기관을 자회사로 보유 겸업
미국의 금융지주회사 제도
지주회사(본체)에서 금융업무를 하지 않고 기획, 경영관리, 자원배분 등에만 전념


제휴 겸업
독립된 금융기관들이 상호 보완적 성격의 상품, 판매망, 기술 등을 공유하는 것
은행의 투신사 수익증권 판매
은행의 증권사 고객에 대한 계좌개설 대행, 현금서비스 등


2. 금융지주회사의 도입 배경과 현황


가. 도입 배경


□ 80년대 후반부터 본격화된 금융자율화의 추세에 따라 금융의 겸업화와 국제화가 촉진되었고, 법제도가 이러한 추세에 따라 완화되기 시작함


□ 세계 각국은 금융산업의 경쟁력 확보를 위해 금융겸업화를 적극적으로 추진하게 되었고, 이에 대응하기 위해 금융기관의 사업체제와 조직도 탄력적인 형태로 바뀌고 있음


□ 특히, 최근 정보통신기술(IT) 발달에 따른 디지털금융의 급속한 발전은 금융산업의 겸업화 추진에 주요 요소로 작용하고 있음
금융기관의 점포를 일일이 방문하지 않고도 인터넷(사이버뱅킹)을 통해 각종 금융업무처리가 가능하게 되었고(원스탑 쇼핑 효과),
정보탐색비용(search cost) 절감 등으로 정보의 비대칭성이 해소되어감에 따라 가장 질 높은 서비스를 제공할 수 있는 전문화된 금융기관이 경쟁우위를 확보할 것으로 예상되기 때문임


나. 도입 현황


□ 세계적으로 금융지주회사를 도입한 나라는 미국, 일본 등이 있으며 영국, 독일 등은 기존법으로도 금융지주회사 설립이 가능


□ 미 국

당초는 은행지주회사* 제도를 도입·운영하여 오다가 금융기관 경쟁력 제고를 위한 금융개혁 차원에서 '99.11월 '금융서비스 현대화법'(FSMA. 일명 Gramm-Leach-Bliley안)을 제정함에 따라 금융지주회사 제도가 도입됨
금융지주회사는 은행 증권 보험업무, 투자회사업무, 종합금융업무 등 제반 금융업무를 자회사 형태로 영위할 수 있음
금융지주회사는 금융업과 일반상공업간의 분리원칙에 따라 일반기업을 자회사로 둘 수 없으며, 대부분 순수지주회사 형태로 운영
금융서비스현대화법 제정·시행 이후 은행지주회사들이 금융지주회사로의 전환을 통해 종합금융그룹화를 적극 추진
미 연방은행(FRB;연방준비위원회)에 의하면 2000. 6. 23일 현재 315개 은행지주회사가 금융지주회사로 전환


※ 은행지주회사(BHC : Bank Holding Company)와 금융지주회사(FHC : Financial Holding Company)의 차이


은행지주회사는 미국에서 발달한 것으로 은행이 순수 지주회사를 만들어 증권, 보험업 등의 자회사를 가질 수 있으나 은행지주회사법('70년, BHCA)에 의해 업무범위가 매우 제한적임. 이 때문에 보험 자회사 진출은 사실상 불가능하였음
반면, 금융지주회사는 금융서비스현대화법('99년, FSMA)에 의해 이러한 은행지주회사법의 제약이 상당 부분 완화됨으로써 은행, 증권, 보험업무, 투자회사업무, 종합금융업무 등 제반 금융업무를 순수 지주회사형태로 운영할 수 있게 됨


□ 일 본


경제력 집중방지 차원에서 독점금지법에 의거 지주회사 설립을 금지하여 오다가 금융환경변화에 대응한 금융기관 경쟁력 강화 차원에서 '97년 관계법령*의 정비를 통하여 금융지주회사의 설립을 허용('98. 3월)


※ '97. 12월 [지주회사 설립 등의 금지해제에 따른 금융관계 법률의 정비 등에 관한 법률] 및 [은행지주회사의 창설을 위한 은행 등에 관계된 합병수속의 특례 등에 관한 법률]을 제정

지주회사는 자회사를 통해 은행, 증권, 보험 등 모든 금융업 영위 가능
주력금융기관의 업종에 따라 은행지주회사, 증권지주회사, 보험지주회사로 구분됨
금융지주회사 설립이 허용된 이후 일본 금융기관들이 금융지주회사 설립을 활발히 추진*하고 있음


※ 최근의 설립 동향
第一勸業 富士 日本興業의 미즈호 Financial Group 설립(2000.10)
三和 東海 아사히은행의 공동 금융지주회사 설립(2001년초)


Ⅱ. 금융지주회사의 도입효과


1. 도입 효과


□ 종합마케팅과 종합금융서비스 체제를 갖출 수 있는 제도적 틀(기반)을 마련해준다는 데에 의의가 있음
기존의 사업부문별 내지 금융자회사들을 묶어 자산운용전문회사, 투자은행, 소비자금융전문회사 등으로 전문화된 금융자회사群으로 재편함으로써 겸업화와 전문화를 강화시킬 수 있게 됨


□ 금융업종간 겸업화를 통해 시너지효과 창출


○ 내부시너지 효과

자회사간 역할 분담이 가능해져 전산시스템, 전문인력 공유와 같은 자원의 공동 활용에 따라 생기는 비용절감이 주된 효과


* 신한은행의 금융지주회사 구상안에서 전산통합회사·채권정리회사·신한종합연구소를 하나로 묶는 지원기능 자회사를 둠. 특히 전산시스템 통합시 전산투자비용을 지금의 절반수준인 연간 1000억원 정도 절감시킬 계획임


○ 외부시너지 효과


고객의 공유, 브랜드(명성)의 공유, 유통망의 공유 등에 따라 금융서비스를 확장시킴으로써 교차판매(cross-selling)* 등으로 수익을 창출하는 효과
특히, 보험업종의 경우 은행부문의 점포를 공유하는 등 채널전략에서 우위를 점하고 복합금융상품을 판매(방카슈랑스)하게 됨


* 교차판매(cross selling)란 이종 기업들이 고객정보를 공유하는 경우, 상대기업이 가지고 있는 고객정보를 활용하여 서로의 상품을 교차하여 판매하는 것을 말함


□ 그룹경영의 효율성을 제고


(순수)지주회사는 개개의 사업 경영을 모두 자회사에 분리하고 이를 기초로 그룹전체의 전사적 차원에서 전략적인 자원배분을 함
거액의 자금(자본)을 유리한 조건으로 조달할 수 있음
일반적으로 지주회사는 자회사보다 재무상황이 좋을 수 있으므로 저리의 융자와 회사채의 발행조건도 유리함. 미국 등에서는 지주회사가 자금조달 기능을 전담하는 것이 일반적임
지주회사 설립을 통해 경영합리화가 가능함
예로 일본의 '미즈호'금융그룹은 '2000년 지주회사를 설립한 후 각 사업부문을 단계적으로 통폐합하여 재무건전성을 제고시켜 일본 정부로부터 지원 받은 공적자금의 조기 상환이 가능할 것으로 봄


□ 리스크 전염 차단이 용이


자회사의 사업 실패시 지주회사는 출자범위 내에서 책임을 지기 때문에 리스크 회피가 용이하고, 한편 금융지주회사와 자회사간, 형제 자회사들 상호간에 차단벽(fire wall)을 설치할 수 있어 리스크 파급을 차단할 수 있음
사업부제의 경우 한 사업부의 실패로 그 피해가 전사에 확산되어 회사 전체가 부실화될 가능성이 높음


□ 오버뱅킹 해소와 수익성 개선


금융지주회사가 금융기관간 통합을 촉진하여 오버뱅킹(금융의 초과 공급)을 해소시켜 금융기관들이 적정 예대마진을 확보할 수 있고,
다양한 금융업무 수행으로 겸업수수료 증대 등으로 수익원 다각화가 가능해짐


2. 금융지주회사의 문제점


□ 은행산업의 집중화 등 과점 형성으로 금융시장의 경쟁을 저하시킴
적은 자본으로 다수 금융기관의 지배가 가능함에 따라 금융산업내 경제력 집중 심화소지와 이로 인해 고객에게 비싼 비용을 지불하게 만들 소지가 있음


□ 핵심역량 강화나 효율적인 조직재편과 같은 전략적인 대안 없이 금융업무의 무분별한 확대차원에서 금융지주회사의 설립을 추진할 경우 방만한 조직으로 득보다 실이 더 클 수 있음


□ 전통적인 예대업무만을 전담하는 은행과 비교해볼 때, 금융지주회사는 주식발행업무나 증권업무를 취급하면서 새로운 위험에 노출될 수 있음


□ 금융지주회사가 전사적 전략차원에서 그룹을 경영한다고 하나 산하 자회사들간에 발생하는 이해상충의 문제가 발생하기 쉽고 이를 조정하는데는 마찰비용이 적지 않게 수반됨


Ⅲ. 세계적인 은행들의 활용 사례


1. 세계적인 은행들의 지주회사 활용


□ 미국 '시티그룹'은 전세계를 대상으로 소비자 금융을 주로 취급하는 상업은행이었으나, 최근 '트레블러즈그룹'과 합병을 통해 보험업무를 추가하였고, '살로만·스미스바니'와의 합병을 통해 투자은행업무와 자산운용업무에서 경쟁력을 새로이 획득하게 되었음


□ '체이스그룹'은 시티그룹과 달리 경쟁력이 다소 취약한 소비자 금융을 미국 국내시장에 한정하고 해외에서는 투자은행업무를 적극 확대하고 있음. 체이스그룹은 시티그룹과 달리 '케미칼은행'과의 합병 이외에는 세계적인 이종업종 금융기관과의 합병을 시행하지 않은 대신에 타 기관의 투자은행 업무팀을 스카우트하는 전략을 취하고 있음


□ 독일의 '도이치뱅크'는 유럽을 중심으로 가계금융 및 기업금융을 종합적으로 취급하다가 국제금융시장에서 투자은행업무와 자산관리업무의 경쟁력을 보완하기 위해 '뱅커스 트러스트'를 인수하여 자산규모 세계 제1의 은행이 되었음


□ 미국의 '멜론그룹'은 한 때 '멜론은행'이 부실화되어 배드뱅크 방식으로 부실자산을 정리한 뒤, 그룹의 경영전략을 자산운용부문에 새로이 특화하면서 경쟁력을 창출하고 있음. 물론 핵심 자회사인 멜론은행이 그룹에서 중심적인 역할을 하나 전통적인 상업은행업무의 수익성이 취약하므로 영업망을 미국동부지역에 한정하는 대신, 주된 수익원을 고수익 가계와 법인을 대상으로 한 자산운용업에서 창출하고 있음


□ 한편, 협동조합 금융기관으로서 금융지주회사를 활용한 대표적인 예로 캐나다의 최대 신용협동조합은행이자 유니버셜뱅킹 형태로 운영되고 있는 '데쟈뎅(Desjardins)그룹'을 들 수 있음. 1989년 캐나다에서 금융지주회사가 허용된 것을 계기로 데쟈뎅그룹은 '90년을 전후하여 지주회사를 활용한 대규모 조직개편을 하였음
데쟈뎅그룹은 지주회사 방식을 통해 다수의 금융자회사를 금융서비스 군별로 재편, 전문 특화함으로써 고객에게 다양하고 질 높은 서비스를 제공할 수 있게 되었고, 지주회사와 자회사별로 인사와 급여체계를 달리하여 금융전문인력을 확보할 수 있는 등 조직의 유연성과 신속성을 거두고 있음


2. 지주회사 금융그룹의 특성


□ 이들은 대부분 지주회사 산하에 적게는 20∼30개, 많게는 100개가 넘는 자회사를 가지고 있으며, 경우에 따라 중간지주회사를 두고 지역별 또는 기능별로 유사한 기관들의 운영을 총괄하고 있음. 다만 도이치뱅크는 산하에 여러 개의 지주회사를 두는 유럽형의 독특한 체제를 취하고 있음


□ 대형화는 동종기관간 합병보다도 이종기관간 합병을 통해 더 많이 이루어지고 있음. 지역금융기관이나 국내시장을 대상으로 하는 금융기관인 경우 동종업종간 합병이 보다 일반적이나, 세계적인 금융기관의 경우에는 이미 동종업종에서 규모가 커졌으므로 이종업종간 합병이 보편적임


□ 수많은 자회사로 이루어진 금융그룹들은 대부분 자회사들을 기능상 몇 개의 그룹단위로 나누고 지주회사의 경영진들이 이들 각 소그룹을 맡아 책임지는 체제를 유지하고 있음. 이는 비록 기관들이 소속은 다를 망정 기능이 유사하므로 같은 소그룹내에서 운영되고 실적이 평가되는 것이 바람직하기 때문임


□ 금융그룹은 조직구조상으로는 자회사들간에 완전한 분업체제를 구축하고 있으나 업무상으로는 협업체제를 추구하고 있음. 이는 분업화를 통해 업무의 중복을 없애고 전문성 및 규모의 경제를 추구하는 한편 업무상으로는 협업체제를 구축하여 시너지 효과를 발휘하기 위함임


□ 금융지주회사의 경우 이종업종간 판매망이 중복되는 경우에는 불필요한 점포를 정리하여 비용을 절감하며, 그 경우에 그룹 전체의 판매망이 재구축되는 경향이 있음. 즉 은행의 점포망을 중심으로 하고 그룹내 타 자회사의 점포망이 보완기능을 하는 것임


□ 금융지주회사 산하에 수많은 자회사가 있지만, 대부분의 경우 지급결제기능 및 가계·기업금융을 동시에 취급하는 상업은행이 자회사중 핵심적인 역할을 담당하게 됨. 증권화의 추세 속에서 전통적인 은행업무보다도 자산운용업무의 수익이 훨씬 크지만, 은행은 금융지주회사 방식 하에서 점포망을 활용한 판매 및 마케팅으로부터 부수적인 수수료 수입을 획득할 수 있음


□ 증권화 및 겸업화의 진전으로 지주회사 산하에 뮤추얼펀드를 자회사로 두고 은행자회사나 자산운용자회사가 이를 직접 운영할 수 있음. 일반적으로 독립계 전문자산운용회사에 비해 은행 뮤츄얼 펀드의 운용실적이 다소 떨어지는 경향이 있으나 시장에서 일정한 수준의 경쟁력을 확보하고 있음


Ⅳ. 향후 금융산업 재편 전망


□ 정보기술(IT) 투자나 인건비 등 각종비용도 크게 절감할 수 있고, 규모가 크고 업무영역이 넓으며 코스트가 적은 금융기관이 강자가 되는 것이 금융기관의 속성인 만큼 금융기관들은 생존을 위해 경쟁적인 합종연횡에 나설 것으로 예상됨


□ 금융지주회사는 급변하는 경영환경 변화에 지주회사의 자회사를 통해 한층 탄력적으로 대응할 수 있다는 점에서, 그리고 정부가 금융지주회사 방식을 통해 금융구조조정을 촉진시킬 경우 다수의 국내금융기관들이 금융지주회사로 전환할 가능이 큼


□ 국내 은행들의 최근 움직임


산업은행은 연내에 보험사를 인수하고, 대우증권, 산은캐피탈 등을 묶어 금융지주회사를 설립할 계획(지주회사 설립사무국 준비)임
신한은행은 모건스탠리의 경영컨설팅 하에 지주회사연구위원회를 출범시켜 신한 금융지주회사구조(안)를 세우는 등 지주회사 설비에 이미 착수하고 있음
하나은행은 금융지주회사 설립을 통해 계열사를 상업은행, 투자은행, 자산관리, 방카슈랑스, 증권중개 등 5개 핵심권역으로 재편할 방침을 금년 2월에 밝힌 바 있음
전략적 제휴를 맺은 한미은행과 하나은행도 금융지주회사를 매개로 제휴의 강도를 높일 가능성이 있음
평화은행과 광주·제주은행 등 지역은행들도 금융지주회사에 참여할 움직임을 나타냄. 금융지주회사를 매개로 전국네트워크를 구성해 점포망을 공유하고, 정보기술(IT)에 대한 중복투자도 피할 수 있을 것으로 봄


□ 일본의 금융지주회사 허용과 금융산업 재편 전망


○ '98년 3월에 금융지주회사를 허용한 일본에서는 전금융업무를 수행하는 유니버셜뱅크가 대거
탄생하고 있는 등 금융산업의 재편 속도는 한층 가속화될 것으로 보고 있음. 일본 금융계 내에서는 금융지주회사 설립에 뒤쳐져서는 살아나지 못할 것이라는 분석이 나오기도 함


○ 미쓰비시종합연구소(1997.6)의 자료에 따르면 향후 금융지주회사제도가 활성화될 경우,종합금융서비스를 제공하기 위해 산하에 전 금융업태를 소유하는 「빅뱅형 금융지주회사」, 지방에 폭넓은 점포망 확보를 위한 「지역특화형 금융지주회사」, 증권회사가 주축이 되는 「증권회사형 금융지주회사」등이 탄생할 것으로 예상함


Ⅴ. 금융지주회사와 농협금융


□ 금융지주회사의 허용이 농협금융에 미칠 영향을 파악하기는 현재로서는 어려움


□ 실제 한국과 같이 금융분업주의가 실시되었던 일본과 미국에서 금융지주회사가 도입된 것은 최근의 일로서 그 영향이 아직 가시화되지 못하고 있음


일본은 '98.3월에 허용된 후 '99년에 첫 금융지주회사가 탄생했고, 미국은 '99.11월에 허용된 후 기존의 은행지주회사(BHC)들이 금융지주회사(FHC)로 전환하고 있어 금융산업에 미치는 영향이 아직 가시화되지 않고 있음. 우리 나라의 경우 현 금융지주회사법(안)은 금융지주회사내 자회사들간에 고객정보 공유 금지, 자회사나 손자회사의 범위와 출자 및 세제 면에서의 제한 등 경쟁력 제고에 필요한 제도들을 모두 포함하지 않고 있다는 지적이 있음


□ 그러나 은행, 증권, 보험이라는 금융의 3대 축이 동일한 금융그룹내에 포함될 수 있는 길이 열렸다는 사실은 획기적인 것임. 과거에 은행과 증권은 연계관계를 가졌으나 보험은 분리되어 있었음. 3대 축이 동일한 금융그룹 산하에 들어옴으로써 종합금융서비스의 제공이 가능해지고 시너지 효과를 기대할 수 있게 됨


□ 앞으로는 금융지주회사를 활용하여 합병과 제휴를 통한 소매금융기반을 확충함과 동시에 자산운용 업무를 강화하려는 움직임이 활발해질 것임. 이는 다양한 금융상품 판매 루트를 확충하여 고객 층을 포섭하기 위함인데, 결국 소매금융기반의 확대 또는 도매금융과 소매 금융을 상호 보완하려는 것임
프랑스와 독일의 대형은행들이 영·미의 투자은행들을 공격적으로 매수하거나 제휴하고 있으며, 미국의 도매금융기관들이 지역은행들과의 합병을 추진하고 있음도 그 예임


□ 따라서 금융지주회사 허용으로 향후 국내 금융지주회사가 활성화될 가능성이 있으며 농협금융에 미칠 영향 또한 적지 않을 것으로 예상됨


○ 일부 시중은행과 지방은행들의 결합으로 지역특화형 금융지주회사가 출현하여 고객과 전산
시스템, 점포망등을 공유하게 된다면, 농협의 경쟁력이 크게 위협받을 수 있음. 특히 상호금융 경쟁력의 가장 큰 강점이 중앙회금융과의 고객 이미지(농협 브랜드)와 시스템(광역 네트워크) 공유라는 점에서 농협의 시너지 효과가 약화될 수 있음


○ 일반은행들이 지주회사를 매개로 보험업과 결합하여 보험상품을 지주회사 내의 은행창구에서 판매하는 방카슈랑스가 보편화될 경우, 그간 농협 공제사업이 누렸던 시너지 효과가 크게 반감될 수 있음


○ 금융지주회사는 자기자본의 확충이 용이해 자본력이 한층 증강될 수 있어 규모화 대형화되는 반면, 자기자본 조달이 어려운 농협은 자본력 열위에 놓일 수 있음


□ 향후 국내은행들이 각자 금융지주회사 방식을 통한 겸업화 과정에서 비교우위 분야에 특화함으로써 경쟁력을 발휘할 것으로 보임. 따라서 농협의 금융사업은 해외 협동조합의 지주회사 활용 사례에 대한 연구 등을 통해 대응해나가야 할 것으로 봄


출처 : 네이버
크리에이티브 커먼즈 라이센스
Creative Commons License
이올린에 북마크하기
Posted by 소리나는연탄.

Leave your greetings here.

  
  
  
  
  
  
  
  
 

 

솔라리스를 사용하다보면 간혹 홈 디렉토리에 코어(core)화일이 생기는 것을 볼 수가 있습니다. 사용에 별 지장이 없다면 그냥 지나쳐도 상관없겠지만, 그 코어가 내가 운영하는 서비스와 관련이 있는 지도 모르므로 확인해보는 습관은 중요합니다.


대개 메모리 접근 위반(Segmentation Violation)으로 생성되는 것이 대부분인데, 솔라리스의 애플리케이션에 포인터 처리가 미숙했거나, 솔라리스가 허용하는 데이타 패싱이 아니었거나 솔라리스에서 허용하는 프로토타입과 상이하게 다르거나 하는 경우에 흔히 생깁니다.

일단 core 화일이 생기게 되면, 해당 애플리케이션의 current directory에 생성됩니다. 대게 많은 애플리케이션들이 홈에서 시작이 되므로, 혹은 홈으로 현재 디렉토리를 옮기게 되므로 홈 디렉토리에 core가 왕왕 생기는 것을 볼 수가 있습니다. 또한, 솔라리스 내장되어 있는 각종 패키지들(gnome)과 같은 데스크 탑 솔루션등도 시작할때 홈에서 시작하므로 버그가 있는 경우 홈에서 core를 많이 볼 수가 있습니다.

core가 생기면 어떤 화일이 어디에서 문제가 생겨서 죽었는 지를 다음과 같이 해서 알 수 있습니다.

#file core
core: ELF 32-bit MSB core file SPARC Version 1, from 'thunderbird-bin'

#pstack core

core 'core' of 3968: /opt/sfw/lib/thunderbird/thunderbird-bin
----------------- lwp# 1 / thread# 1 --------------------
ff3416e0 _lwp_kill (b, ffbfe4b0, 0, b, fc00, 1) + 8
0051086c ???????? (b, 0, 510748, 510400, a, c4)
ff340618 __sighndlr (b, 0, ffbfe620, 510784, 0, 1) + c
ff335710 call_user_handler (b, ffbffeff, 0, 0, fe2b2000, ffbfe620) + 3b8
010b4794 ???????? (6e6e800, ff0a49bc, 24002400, 28002800, 28002800, 6e6e800)
010b5b44 ???????? (6cf5090, 63636c8, ff000000, 0, 80000000, ff0a39e4)
ff0a6fc0 __1cYnsOutputStreamReadyEventMEventHandler6FpnHPLEvent__pv_ (6c6fa74,
6c6faa8, 6c6fa70, 6cf5090, 10b5ab8, 18d79a0) + 34
ff0c03a0 PL_HandleEvent (6c6fa74, 1985454, ff0a6f8c, 1985454, 1985450, 6c6fa74) + 14
ff0c02b8 PL_ProcessPendingEvents (12, 1, d, 0, 0, 1985450) + 7c
ff0c23cc __1cQnsEventQdDueueImplUProcessPendingEvents6M_I_ (196dd08, 80004000,
ff000000, 0, 0, 1aef090) + 20
0072b840 ???????? (1af2f38, 1, 196dd08, 1, 1, ff0c23ac)
fea55ac8 g_main_dispatch (196e898, feabec00, 0, 0, fffffffd, ffffffef) + 19c
fea56ffc g_main_context_dispatch (196e898, c8, 0, 1, feabec00, 196e898) + 9c
fea574c8 g_main_context_iterate (1, 1, 1, 196e898, 196e8a0, 9) + 454
fea57c44 g_main_loop_run (1b99fe0, feabec00, ff339c58, 199a2f8, feaaa800, feaaa800) + 348
fee2a424 gtk_main (0, 0, 1b99fe0, 1aa4500, feff1eb0, 4ce0) + d0
0072bba4 ???????? (1aa6ac8, 196dd08, 18332d4, 72bbc0, c1f30000, 0)
....

위의 core는 thunderbird-bin이 생성한 것임을 알 수가 있습니다.
위의 core는 불행하게도 두가지 문제가 있는데, 하나는 debugging symbol을 가지고 있지 않는 함수가 있다는 것이고, 하나는 C++에 의한 맹글링으로 인해 함수 이름을 알아보기 어렵다는 점이 있습니다.

일단, C++ mangling 문제는 다음과 같이 함으로써 해결할 수 있습니다.

$pstack core | /opt/SUNWspro/bin/c++filt | less
core 'core' of 3968: /opt/sfw/lib/thunderbird/thunderbird-bin
----------------- lwp# 1 / thread# 1 --------------------
ff3416e0 _lwp_kill (b, ffbfe4b0, 0, b, fc00, 1) + 8
0051086c ???????? (b, 0, 510748, 510400, a, c4)
ff340618 __sighndlr (b, 0, ffbfe620, 510784, 0, 1) + c
ff335710 call_user_handler (b, ffbffeff, 0, 0, fe2b2000, ffbfe620) + 3b8
010b4794 ???????? (6e6e800, ff0a49bc, 24002400, 28002800, 28002800, 6e6e800)
010b5b44 ???????? (6cf5090, 63636c8, ff000000, 0, 80000000, ff0a39e4)
ff0a6fc0 void*nsOutputStreamReadyEvent::EventHandler(PLEvent*) (6c6fa74, 6c6faa8, 6c6fa70, 6cf5090, 10b5ab8, 18d79a0) + 34
ff0c03a0 PL_HandleEvent (6c6fa74, 1985454, ff0a6f8c, 1985454, 1985450, 6c6fa74) + 14
ff0c02b8 PL_ProcessPendingEvents (12, 1, d, 0, 0, 1985450) + 7c
ff0c23cc unsigned nsEventQueueImpl::ProcessPendingEvents() (196dd08, 80004000,
ff000000, 0, 0, 1aef090) + 20
0072b840 ???????? (1af2f38, 1, 196dd08, 1, 1, ff0c23ac)
fea55ac8 g_main_dispatch (196e898, feabec00, 0, 0, fffffffd, ffffffef) + 19c
fea56ffc g_main_context_dispatch (196e898, c8, 0, 1, feabec00, 196e898) + 9c
fea574c8 g_main_context_iterate (1, 1, 1, 196e898, 196e8a0, 9) + 454
fea57c44 g_main_loop_run (1b99fe0, feabec00, ff339c58, 199a2f8, feaaa800, feaaa800) + 348
fee2a424 gtk_main (0, 0, 1b99fe0, 1aa4500, feff1eb0, 4ce0) + d0
0072bba4 ???????? (1aa6ac8, 196dd08, 18332d4, 72bbc0, c1f30000, 0)
....

c++filt는 썬 스튜디오를 설치하면 따라오는 유틸리티입니다.
기본적으로 /usr/ccs/bin/nm도 디맹글링을 지원합니다만 사용 환경이 다릅니다.

위에서 발생한 core는 thunderbird-bin이 링크하는 동적 라이브러리에서 출력 스트림 이벤트 핸들러에서 발생한 문제임을 알수가 있습니다. 어느 라이브러리에서 발생했는지 알기 위해서는 커널 디버거인 mdb를 사용해야 합니다.

> mdb core
Loading modules: [ libc.so.1 libuutil.so.1 ld.so.1 ]
> $C
ffbfe3f0 libc.so.1`_lwp_kill+8(b, ffbfe4b0, 0, b, fc00, 1)
ffbfe450 0x51086c(b, 0, 510748, 510400, a, c4)
ffbfe4c0 libc.so.1`__sighndlr+0xc(b, 0, ffbfe620, 510784, 0, 1)
ffbfe520 libc.so.1`call_user_handler+0x3b8(b, ffbffeff, 0, 0, fe2b2000, ffbfe620)
ffbfe8d8 0x10b4794(6e6e800, ff0a49bc, 24002400, 28002800, 28002800, 6e6e800)
ffbfe940 0x10b5b44(6cf5090, 63636c8, ff000000, 0, 80000000, ff0a39e4)
ffbfe9a8
libxpcom_core.so`__1cYnsOutputStreamReadyEventMEventHandler6FpnHPLEvent__pv_+0x34(6c6fa74, 6c6faa8, 6c6fa70, 6cf5090, 10b5ab8, 18d79a0)
ffbfea08 libxpcom_core.so`PL_HandleEvent+0x14(6c6fa74, 1985454, ff0a6f8c,
1985454, 1985450, 6c6fa74)
ffbfea68 libxpcom_core.so`PL_ProcessPendingEvents+0x7c(12, 1, d, 0, 0, 1985450)
ffbfeac8 libxpcom_core.so`__1cQnsEventQdDueueImplUProcessPendingEvents6M_I_+0x20(196dd08, 80004000, ff000000, 0, 0, 1aef090)
ffbfeb30 0x72b840(1af2f38, 1, 196dd08, 1, 1, ff0c23ac)
ffbfeb90 libglib-2.0.so.0.400.1`g_main_dispatch+0x19c(196e898, feabec00, 0, 0,
fffffffd, ffffffef)
ffbfebf8 libglib-2.0.so.0.400.1`g_main_context_dispatch+0x9c(196e898, c8, 0, 1,
feabec00, 196e898)

....

위에서 $C 명령어는 core가 유도된 스레드의 스택을 보여줍니다.
장애의 소스가 되는 관심있는 함수와 모듈을 알수 있습니다.
libxpcom_core.so를 확인하게 되면 앞서 보았던, void*nsOutputStreamReadyEvent::EventHandler(PLEvent*)
임을 알 수 있기 때문입니다. 따라서, 개발자들은 이 함수의 소스를 확인해야 합니다.

지금부터는 이 함수의 어느 부분이 문제인지 확인하기 위해서는 소스 디버거나 dtrace를 사용해야만 하겠죠.

그러나, 경험적으로 core의 몇가지 정보를 더 얻을 수 있다면, 문제가 무엇인지 직감하는데 도움이
되는 경우도 있습니다.

예를 들면, 해당 core가 어떤 크리덴셜(퍼미션)을 가지고 실행했는가 ?
해당 코어는 어떤 환경에서 실행되었는가등을 알면 매우 큰 도움이 되는 경우가 있습니다.
다음과 같은 유틸리티를 통해서 알수가 있습니다.

#pargs -e core
#pldd core
#pcred core

크리에이티브 커먼즈 라이센스
Creative Commons License
이올린에 북마크하기
Posted by 소리나는연탄.

Leave your greetings here.

  
  
  
  
  
  
  
  
 

[ 마포구 ]

태안 기름유출사고 긴급자원봉사자를 모집합니다.

일     시 : 2007.12.16(일)

장     소 : 아현초등학교에서 오전 7시30분에 출발

모집기관: 재난특수구조단 마포지구대

                (대장 정재주 010-2066-8440)

모집인원: 40명(선착순으로 모집)

준 비 물 : 고무장갑,버려도 되는 헌옷 마스크 등

 문     의 : 재난특수구조단 마포지구대

                (대장 정재주 010-2066-8440)


오전 7시30분에 아현초등학교에서 출발하므로 7시까지
아현초등학교에 집합하셔야됩니다.

자원봉사활동은 현지에서 오후4시까지 하고 4시30분에
출발예정입니다.  많은 참여 바랍니다.

http://bongsa.mapo.go.kr/Programs/User/Information_Notice/read.asp?Num=1173


[ 영등포구 ]

태안 기름유출 현장 복구에 참여할 자원봉사자를 긴급 모집하오니 많은 참여 바랍니다.

    * 활동일시 : 2007.12.14(금) 07:00~21:00

    * 활동지역 : 충청남도 태안군 일대 (서울시 지정장소)

    * 모집인원 : 80명~85명

    * 신청자격 : 봉사경험이 있는 신체건강한 봉사자

                 (수해 등 재해복구 경험이 있으신 분 꼭 신청해 주세요)

    * 활동내용 : 해변 및 모래사장에 표착된 기름막 제거

    * 신청방법 : 자원봉센터에 유선으로 신청(2670-4154~7)

    * 집결장소 및 시간 : 자원봉사센터에 06:50분 집결(시간엄수)

    * 개인준비물 : 갈아입을 옷, 기름흡착에 사용할 헌옷

http://www.ydp.go.kr/MultiBoard/content.asp?code=A97&number=3529&path=E030010

크리에이티브 커먼즈 라이센스
Creative Commons License
이올린에 북마크하기
Posted by 소리나는연탄.

Leave your greetings here.

  
  
  
  
  
  
  
  
 
« Previous : 1 : ... 6 : 7 : 8 : 9 : 10 : 11 : 12 : 13 : 14 : ... 33 : Next »