회사에서는 vim 으로 프로그래밍을 하는데, 컬러가 너무 강한색이라 그런지 일이 끝나면 언제나 충열되더군요


그래서 vim 색상을 눈에 피로하지 않는 스키마로 바꾸는데 좋은 사이트가 있어서 소개합니다.


1. http://bytefluent.com/vivify/



2. http://www.vimtax.com/


3. http://sweyla.com/themes/


역시나 vim!

저작자 표시 비영리 변경 금지
신고
블로그 이미지

프로그래머 지향자 RosaGigantea

바쁜 일상 생활중의 기억 장소

Tag vim

리눅스에서 프로세스 강제로 죽이면서 코어 남기려면


core 가 생성되게 셋팅하시고(ulimit -c 참고)
kill -SIGSEGV pid 로 강제 시그널을 날려서 core을 남기게 할 수 있습니다.



저작자 표시 비영리 변경 금지
신고
블로그 이미지

프로그래머 지향자 RosaGigantea

바쁜 일상 생활중의 기억 장소

第10章 著名な脆弱性対策
バッファオーバーフロー: #4 あふれを検出するデバッグ

領域あふれの問題の検出については、ロジックが複雑に入り組んでいる場合、ソースコードから見いだすのは容易でない。そのような場合、デバッガ等のツールの下で対象のプログラムを動かして、問題を見つけ出すことになる。

スタックおよびヒープにおけるあふれを検出するためのコンパイラのオプションやデバッグ・ツールがいくつか存在する。

次にその主なものを紹介する。

あふれの検出
図10-4: あふれの検出

あふれの検出等に使うことのできるデバッグ・ツール

ヒープにおける領域あふれやダブルフリー等の問題を検出できるツールをふたつ紹介する。ひとつは独立したツール、もうひとつは統合開発環境の中の機能である。

(1) Valgrind [GNU/Linux]

ヒープデバッガを中心とした GNU/Linux 専用のツールスイートである。割当領域外への書き込みや、メモリリークを検出することができる。

Valgrind が備えるツールには、下記のようなものがある。

  • Memcheck
    最も主要なツール、ヒープデバッガ。動的メモリに関わる諸問題を検出する(領域外のアクセス、未初期化領域の参照、不正free、メモリリーク、重複領域のmemcpy)
  • Cachegrind
    キャッシュプロファイラ。CPUキャッシュをエミュレートし、使用状況を調べることができる
  • Callgrind
    Cachegrind プラス呼び出しグラフ生成
  • Massif
    ヒーププロファイラ
  • Helgrind
    スレッドデバッガ ほか
例: Valgrind の Memcheck
対象プログラムをデバッグモード(gcc -g 等)でコンパイルしてあると、Valgrindは問題とともにソースコード位置も知らせてくれる。
   1: $ valgrind --tool=memcheck --leak-check=yes test_program
...
			↓≪≪実行途中における、 malloc()した領域からのあふれの検出≫≫
   8: ==1929== Invalid write of size 1
   9: ==1929==    at 0x8048970: header_getContentType (test_program.c:110)
  10: ==1929==    by 0x8049A58: block_processHeader (test_program.c:586)
  11: ==1929==    by 0x8049EA6: block_processField (test_program.c:673)
  12: ==1929==    by 0x8049F80: main_processBlock (test_program.c:712)
  13: ==1929==  Address 0x1BA4B4B2 is 0 bytes after a block of size 434 alloc'd
  14: ==1929==    at 0x1B904DF0: malloc (vg_replace_malloc.c:131)
  15: ==1929==    by 0x8048930: header_getContentType (test_program.c:106)
  16: ==1929==    by 0x8049A58: block_processHeader (test_program.c:586)
  17: ==1929==    by 0x8049EA6: block_processField (test_program.c:673)	
  18: ==1929==
...

			↓ ≪≪プログラム終了時、メモリリークの検出≫≫
1048: ==1929== 60907 bytes in 134 blocks are definitely lost in loss record 12 of 12
1049: ==1929==    at 0x1B904DF0: malloc (vg_replace_malloc.c:131)
1050: ==1929==    by 0x8048930: header_getContentType (test_program.c:106)
1051: ==1929==    by 0x8049A58: block_processHeader (test_program.c:586)
1052: ==1929==    by 0x8049EA6: block_processField (test_program.c:673)
1053: ==1929== 

			↓ ≪≪メモリリークのサマリ≫≫
1054: ==1929== LEAK SUMMARY:
1055: ==1929==    definitely lost: 60907 bytes in 134 blocks.
1056: ==1929==    possibly lost:   334 bytes in 1 blocks.
1057: ==1929==    still reachable: 1512 bytes in 14 blocks.
1058: ==1929==         suppressed: 0 bytes in 0 blocks.

参照URL http://valgrind.org/

(2) Application Verifier [Visual Studio 2005, Windows]

領域あふれの検出に使うことはできないが、Visual Studio に備わっているApplication Verifier(日本語名「アプリケーションの検証」)は、Visual C++ のデバッガとともに動作させると、ヒープのダブルフリー等の不具合を検出してくれるものである。

他にも、ハンドルの検証やロックの検証等の機能がある。

参照URL http://www.microsoft.com/japan/msdn/vstudio/

あふれを検出できるランタイム・ライブラリの機能

通常のランタイムライブラリの代わりに、領域あふれ等を検出する能力が組み込まれたライブラリをプログラムにリンクしてデバッグを行う方法がある。

(1) Mudflap [GCC]

バッファオーバーフロー、メモリリーク、ポインタの誤使用等を実行時に検出してくれるライブラリおよびGCCのコンパイルオプション。

Valgrind に比べて、解析速度が速く、stack, data, bss 変数のチェックが行えるが、コンパイルオプションとライブラリの追加オプションが必要である。

GCCオプション: -fmudflap -lmudflap
マルチスレッドの場合のGCCオプション: -fmudflapth -lmudflapth


プログラム example3.c
 1 #include <string.h>
 2 
 3 sub () {
 4     char c8[8];
 5     strcpy(c8, "1234567890");
 6 }
 7
 8 main () {
 9     sub();
10 } 
コンパイルするコマンドの例
cc -fmudflap -lmudflap example3.c -o example3
実行例
$ ./example3
*******
mudflap violation 1 (check/write): time=1167124492.737106 ptr=0xbff80720 size=11
pc=0x5d5f9d location=`(strcpy dest)'
      /usr/lib/libmudflap.so.0(__mf_check+0x3d) [0x5d5f9d]
      /usr/lib/libmudflap.so.0(__mfwrap_strcpy+0x158) [0x5e2368]
      ./example3(sub+0x3c) [0x8048630]
Nearby object 1: checked region begins 0B into and ends 3B after
mudflap object 0x8fb2588: name=`example3.c:4 (sub) c8'
bounds=[0xbff80720,0xbff80727] size=8 area=stack check=0r/3w liveness=3
alloc time=1167124492.700013 pc=0x5d59dd
number of nearby objects: 1

環境変数 MUDFLAP_OPTIONS を設定すると次のようなこともできる。

・Mudflapを一時的に無効にする

$ MUDFLAP_OPTIONS="-mode-nop" ./example3

・タイムスタンプとバックトレースを止める

$ MUDFLAP_OPTIONS="-no-timestamps -backtrace=0" ./example3
タイムスタンプとバックトレースを止めて実行した例
$ MUDFLAP_OPTIONS="-no-timestamps -backtrace=0" ./example3
*******
mudflap violation 1 (check/write): time=1167124513.569876 ptr=0xbff0d680 size=11
pc=0xd31f9d location=`(strcpy dest)'
Nearby object 1: checked region begins 0B into and ends 3B after
mudflap object 0x9f7d5f0: name=`example3.c:4 (sub) c8'
bounds=[0xbff0d680,0xbff0d687] size=8 area=stack check=0r/3w liveness=3
alloc time=0.000000 pc=0xd319dd
number of nearby objects: 1

参照URL http://gcc.gnu.org/wiki/Mudflap_Pointer_Debugging

(2) MALLOC_CHECK_ [glibcを制御する環境変数]

MALLOC_CHECK_ は、glibc(GNU C Library)がもつ malloc() - free() 関連のチェック機能を活性化させる環境変数である。この環境変数に値を定義すると、malloc() で割り当てたメモリブロックの簡単な保護と異常検出の機能がはたらき、free() 関数が呼び出されたときに次の問題が生じていないかのチェックが行われるようになる。

  • malloc() で割り当てたブロックの手前のメモリの4バイト分のどこかが不正な値で上書きされていないか
  • malloc() で割り当てたブロックの後続のメモリ1バイト分が不正な値で上書きされていないか
  • すでに free() されたポインタを再度 free() しようとしていないか

環境変数 MALLOC_CHECK_ に設定された値に応じ、glibc は次のように振る舞う。

  • MALLOC_CHECK_=0 上記の問題でプログラムに異常をきたすのを防ぐが報告はしない
  • MALLOC_CHECK_=1 問題を検出してメッセージを出す
  • MALLOC_CHECK_=2 問題を検出してプロセスをアボートさせる
  • MALLOC_CHECK_=3 1 と 2 の両方を行う

参照URL http://www.gnu.org/software/libc/manual/html_node/Heap-Consistency-Checking.html

(3) -D_FORTIFY_SOURCE=n [GCC, glibc]

C言語の標準ランタイム関数を使用するプログラムの実行がよりセキュアに行われるよう、マクロの仕組みを用いて呼び出すライブラリ関数をより堅固なバージョンに置き換えるglibc(GNU C Library)の機能である。

1) 呼び出すライブラリ関数を切り替えるオプション

GCC にコンパイルオプション -D_FORTIFY_SOURCE=1 あるいは =2 を指定すると、あふれを起こしやすい strcpy() のような関数がマクロ展開によって同様な処理を行うが領域あふれを検査するよう対策された別の関数 __strcpy_chk() に置き換わる。
プログラム実行時にあふれ等の問題が検出されたときは、プロセスの実行が abort()によって中止される。

この方法を使うと、ソースコードを変更する必要がなく、コンパイルのし直しのみであふれ検出機能をはたらかせることができる。

GCCに指定するオプション: -O1 -D_FORTIFY_SOURCE=1 または =2

この機能を使用するときは、コンパイラの最適化オプションを -O1 またはそれ以上のレベルで指定する必要がある。


プログラム example1.c
1 #include <stdio.h>
2 main () {
3 	char buf[4];
4 	gets (buf);
5 	puts (buf);
6 }
コンパイルと実行の例
$ gcc -O1 -D_FORTIFY_SOURCE=2 example1.c -o example1
$ ./example1
aaaa
*** buffer overflow detected ***: ./example1 terminated
======= Backtrace: =========
/lib/libc.so.6(__chk_fail+0x41)[0x464d7161]
/lib/libc.so.6(__gets_chk+0x174)[0x464d70c4]
./example2[0x804840d]
/lib/libc.so.6(__libc_start_main+0xdc)[0x4640bf2c]
./example2[0x8048351]
======= Memory map: ========
00651000-00652000 r-xp 00651000 00:00 0          [vdso]
08048000-08049000 r-xp 00000000 fd:00 914420     /home/test/example2
08049000-0804a000 rwxp 00000000 fd:00 914420     /home/test/example2
0947a000-0949b000 rwxp 0947a000 00:00 0 
45a27000-45a40000 r-xp 00000000 fd:00 948678     /lib/ld-2.5.so
    ...省略...
bfa0c000-bfa22000 rw-p bfa0c000 00:00 0          [stack]
アボートしました
$

2) コンパイル時にも問題を検出

判断が可能な場合にはコンパイル時にもあふれの警告が出力される。


プログラム example2.c
1 #include <string.h>
2 main () {
3 	char c8[8];
4 	strcpy (c8, "1234567890");
5 }

3) 運用における使用

-D_FORTIFY_SOURCE によって導入されるチェックロジックのオーバーヘッドは比較的小さいと言われている。デバッグ時のみならず、プログラムのリリース後もこのオプションを使用することによって攻撃に備えるのもひとつの方法である。

(4) /RTCs [Visual Studio 2005, Windows]

スタック上の変数領域のあふれを実行時に検出してくれる、Visual C++ のコンパイルオプション。

文字型配列(char[ ])のみならず、スタック上のすべての変数を検査してくれるのが特徴である。変数の大きさが1バイトしかなくても、型がintやポインタであってもあふれが検査される。

あふれを検出するのに使われる方法は、変数ひとつひとつの前後に 0xCCCCCCCC の値をもつ4バイトのワードが置かれ、これが壊れていないか、関数からのリターン時に調べるというものである。この /RTCs の検査は、/GS のスタック破壊検査よりも先に行われる。


プログラム
func () {
   int	i;
   char	c16[16];
   char	*p;
   int	j;

   i = 0x11111111;
   memset (c16, 0x22, sizeof(c16));
   p = 0x33333333;
   j = 0x44444444;
   c16[16] = 0xFF;
   return 0;
}
func() 関数からリターンする直前のスタックの内容
0x0012FE20  cccccccc cccccccc cccccccc cccccccc  フフフフフフフフフフフフフフフフ
0x0012FE30  cccccccc cccccccc 44444444 cccccccc  フフフフフフフフDDDDフフフフ
                              ↑int  j
0x0012FE40  cccccccc 33333333 cccccccc cccccccc  フフフフ3333フフフフフフフフ
                     ↑char *p
0x0012FE50  22222222 22222222 22222222 22222222  """"""""""""""""
                     ↑char c16[16]
0x0012FE60  ccccccff cccccccc 11111111 cccccccc  .フフフフフフフ....フフフフ
                  **          ↑int i
0x0012FE70  9bbfcf2a 0012ff48 004114a3 00000000  *マソ・H...」.A.....
0x0012FE80  00000000 7ffdf000 cccccccc cccccccc  .....・..フフフフフフフフ
0x0012FE90  cccccccc cccccccc cccccccc cccccccc  フフフフフフフフフフフフフフフフ

※ c16[ ] の前後に 0xcc 以外が書き込まれていることがあふれとして検出される

参照URL http://www.microsoft.com/japan/msdn/vstudio/

저작자 표시 비영리 변경 금지
신고
블로그 이미지

프로그래머 지향자 RosaGigantea

바쁜 일상 생활중의 기억 장소

Tag 메모리
출처 : http://studyfoss.egloos.com/5278709
gcc: 4.4.3



mudflap 라이브러리는 gcc 내에 포함된 메모리 검사 기능으로
포인터를 통한 메모리 접근 시 이를 검사하는 코드를 원래의 코드 내에 직접 삽입하는 방식이다.
mudflap은 gcc와 통합되어 있기 때문에 코드를 생성하는 과정 내에서
포인터를 통한 메모리 접근을 인식하면 자동으로 그에 대한 검사 코드를 만들 수 있다.

기본적인 동작 방식은 미리 할당된 메모리 영역에 대한 정보를 등록하여 데이터베이스를 구성해 두고
포인터를 이용한 메모리 접근 시 등록된 메모리 영역에 대한 접근인지를 체크하는 식이다.

전역 변수 및 문자열 상수, 명령행 인자, 환경 변수 등은 프로그램 실행 시작 시 자동으로 등록되며
스택 변수의 경우 해당 block에 진입/탈출 시 동적으로 등록/해제된다.
help 변수의 경우도 heap 할당 함수를 (malloc, calloc 등) wrapping하여
해당 영역에 대한 정보를 등록하도록 되어 있다.

이러한 등록 과정은 __mf_register() 함수가 수행하는데
기본적으로 메모리 영역의 시작 주소, 크기, 객체 타입, 이름 등의 정보가 저장된다.
여기서 객체 타입은 heap, stack, static 등을 구분하기 위한 정수값이며
객체 이름은 "파일명:줄번호:행번호 (함수명) 변수명"의 형태이다.

간단한 예제를 살펴보기로 하자.

#include <stdio.h>

int main(void)
{
  char buf[16];
  char msg[] = "Hello mudflap!";
  char *p = msg;
  p[-1] = '\0';
  return 0;
}


p 변수는 원래의 msg 영역을 벗어난 메모리 영역에 접근했다.
이 경우 사실은 msg 아래에는 buf가 할당되어 있으니 메모리 자체로는 접근이 가능한 구역이긴 하다.
하지만 mudflap은 코드에서 buf에 접근하지 않았으므로 buf를 등록하지 않기 때문에
이러한 종류의 메모리 접근도 오류로 잡아낼 수 있다.

mudflap을 이용하도록 컴파일하려면 -fmudflap 옵션을 추가해야 한다.
(multi-thread 프로그램에서 이용할 경우에는 mudflapth 옵션을 대신 이용해야 한다.)
이에 관련된 builtin spec들을 살펴보면 다음과 같다.

*cpp_unique_options:
    %{fmudflap:-D_MUDFLAP -include mf-runtime.h}
    %{fmudflapth:-D_MUDFLAP -D_MUDFLAPTH -include mf-runtime.h} 

*cc1_options:
    %{fmudflap|fmudflapth:-fno-builtin -fno-merge-constants}

*mfwrap:
    %{static: %{fmudflap|fmudflapth:  --wrap=malloc --wrap=free --wrap=calloc --wrap=realloc
                                      --wrap=mmap --wrap=munmap --wrap=alloca}
        %{fmudflapth: --wrap=pthread_create}}
    %{fmudflap|fmudflapth: --wrap=main}

*mflib:
    %{fmudflap|fmudflapth: -export-dynamic}

*link_command:
    %(mfwrap) %(link_libgcc) %o %(mflib)


cpp 실행 시에는 _MUDFLAP 매크로를 정의하고 mf-runtime.h 파일을 #include한다.
cc1 실행 시에는 문자열/메모리 관련 함수들을 최적화하지 않고 mudflap을 통하여 실행하기 위해
builtin 함수를 사용하지 않도록 하고 동일한 문자열 상수로 별도로 관리하기 위해 병합하지 않는다.
링크 시에는 main 함수를 wrapping하기 위해 실행 파일 내의 심볼들도 dynamic symbol table을 통해 공개하며
특히 static 빌드 시에는 동적 메모리 함수들도 관리하기 위해 모두 wrapping한다.

다음과 같이 컴파일 후 실행하면 아래와 같은 메시지를 출력할 것이다.
(-fmudflap 옵션을 주고 맨 뒤에 -lmudflap을 링크하도록 지정해야 한다.)
우분투의 경우 libmudflap0 와 libmudflap0-dev 패키지를 설치하면 테스트해 볼 수 있다.

$ gcc -fmudflap test.c -lmudflap
$ ./a.out
*******
mudflap violation 1 (check/write): time=1269503302.202747 ptr=0xbfb80bdc size=1
pc=0xb77a2d6d location=`test.c:8:3 (main)'
      /usr/local/lib/libmudflap.so.0(__mf_check+0x3d) [0xb77a2d6d]
      ./a.out(main+0xcf) [0x80488d3]
      /usr/local/lib/libmudflap.so.0(__wrap_main+0x49) [0xb77a2569]
Nearby object 1: checked region begins 1B before and ends 1B before
mudflap object 0x8627588: name=`test.c:6:8 (main) msg'
bounds=[0xbfb80bdd,0xbfb80beb] size=15 area=stack check=0r/0w liveness=0
alloc time=1269503302.202732 pc=0xb77a250d
number of nearby objects: 1


메시지는 메모리 쓰기 접근 시 오류가 났음을 보여주며 (check/write)
접근 주소 및 크기와 소스 코드에서의 위치까지 표시해 준다.
그 아래는 stack backtrace 정보를 출력한 것이다.
그 아래는 접근한 영역의 근처에 있는 등록된 메모리 영역 정보를 표시하는 것으로
1 바이트 뒤에 "test.c:6:8 (main) msg" 객체가 있다는 것을 보여준다.
해당 객체의 메모리 위치는 bounds 속성에서 볼 수 있고, 객체 타입(area)은 stack이다.

그럼 mudflap은 어떻게 스택에 할당된 메모리 영역을 관리할 수 있을까?
가장 기본적으로는 포인터에 대한 대입 (assignment) 연산이 일어나는지 확인한 후
해당 (즉, 포인터에 대입된) 메모리 영역을 __mf_register() 함수로 등록하는 것이다.

gcc는 코드 생성 과정에서 포인터를 통한 스택 접근을 확인하면
다음과 같은 식으로 (C++의 예외 처리 방식을 이용하도록) 코드를 변경한다.
위에서 코드 컴파일 시 -fdump-tree-mudflap1 옵션을 주면 이 과정을 볼 수 있다.

$ gcc -fmudflap -fdump-tree-mudflap1 test.c -lmudflap
$ cat test.c.008t.mudflap1 

;; Function main (main)

main ()
{
  char * D.1297;
  int D.1298;
  char buf[16];
  char msg[15];
  char * p;

  try
    {
      __mf_register (&msg, 15, 3, "test.c:6:8 (main) msg");
      msg = "Hello mudflap!";
      p = &msg;
      D.1297 = p + -1;
      *D.1297 = 0;
      D.1298 = 0;
      return D.1298;
    }
  finally
    {
      __mf_unregister (&msg, 15, 3);
    }
}


위에서 보듯이 해당 코드는 try-finally 블록으로 감싸지고
코드의 시작과 finally 부분에 msg를 등록/해제하는 register/unregister 함수가 추가되었다.
참고로 3번째 인자로 주어진 3이라는 값은 해당 객체가 stack 타입 임을 나타낸다. (__MF_TYPE_STACK)

위의 코드는 아직 mudflap 처리가 완전히 끝난 것이 아니라서 빠져있지만
최종적으로 메모리를 역참조(dereference) 하는 부분에는 메모리 접근을 검사하는 코드가 추가될 것이다.
GNU C 확장 기능인 statement expression을 이용하여 표현하면 p->f 식의 메모리 접근은
({ __mf_check(p, sizeof(*p), __MF_CHECK_WRITE, location); p; })->f 와 같은 형태로 바뀐다.
실제로는 lookup cache 검사 및 필드 f의 위치로 인해 이와는 약간 다른 형태의 코드가 생성된다.

또한 string이나 memory 관련 표준 함수들도 mudflap에 의해 wrapping되어
실제 함수 수행 전에 먼저 메모리 영역에 대한 검사가 이루어진다.
다음은 memcpy 함수에 대한 wrapper 루틴이다.

WRAPPER2(void *, memcpy, void *dest, const void *src, size_t n)
{
  TRACE ("%s\n", __PRETTY_FUNCTION__);
  MF_VALIDATE_EXTENT(src, n, __MF_CHECK_READ, "memcpy source");
  MF_VALIDATE_EXTENT(dest, n, __MF_CHECK_WRITE, "memcpy dest");
  return memcpy (dest, src, n);
}


여기서 실제 검사하는 MF_VALIDATE_EXTENT 매크로에서 수행하는데
이는 다음과 같이 정의되어 있다.

#define MF_VALIDATE_EXTENT(value,size,acc,context) \
 do { \
  if (UNLIKELY (size > 0 && __MF_CACHE_MISS_P (value, size))) \
    if (acc == __MF_CHECK_WRITE || ! __mf_opts.ignore_reads) \
    __mf_check ((void *) (value), (size), acc, "(" context ")"); \
 } while (0)


먼저 주어진 메모리 영역을 최근에 참조한 캐시 (__mf_lookup_cache)에서 찾아보는데
찾지못한다면 (__MF_CACHE_MISS_P()가 true를 반환) __mf_check()를 호출하여 등록된 전체 객체를 모두 찾아본다.
이 때 설정에 따라 read 접근인 경우 검사를 수행하지 않을 수도 있다. (-ignore-reads)

동적 메모리 함수의 경우에는 마찬가지로 wrapper 함수를 만들어서 내부적으로 실제 함수를 호출한 뒤
결과로 얻어진 영역을 __mf_register() 함수를 통해 자동으로 등록하도록 되어 있다.

하지만 이렇게 하더라도 모든 메모리 정보를 추적할 수는 없는 경우가 있다.
예를 들어 mudflap을 이용하지 않고 빌드된 외부 라이브러리를 이용하는 경우
해당 라이브러리 함수 내에서 할당된 동적 메모리 등의 경우는 mudflap에서 알아낼 수가 없다.

이 경우 프로그램에서 해당 메모리 접근 시 violation이 발생할 수 있는데
(혹은 어떤 이유로든 mudflap이 인식하지 못하는 정상적인 영역에 접근 시에도 마찬가지다)
이런 상황에 대처하기 위해 mudflap이 제공하는 몇 가지 heuristic을 이용할 수 있다.
이는 MUDFLAP_OPTIONS라는 환경 변수를 다음 중 하나로 설정하면 된다.

  • -heur-proc-maps : 리눅스에서 제공하는 /proc/<pid>/maps 파일에 등록된 영역이면 허가한다.
  • -heur-stack-bound : 현재 할당된 스택 영역 내의 접근은 허가한다.
  • -heur-start-end : 프로그램의 text/data/bss 영역 내의 접근은 허가한다.
  • -heur-argv-environ : 프로그램 실행 시 주어진 argv, env 배열에 대한 접근은 허가한다. (기본값: enable)


이 외에도 MUDFLAP_OPTIONS는 mudflap의 전반적인 동작 모드를 변경하거나
violation 발생 시 동작 변경 및 추가적인 정보를 표시할 수 있는 등의 여러가지 옵션을 설정할 수 있다.
옵션의 전체 목록은 mudflap을 이용해 빌드된 프로그램 실행 시 MUDFLAP_OPTIONS에 -help를 설정하면 볼 수 있다.


=== 참고 문헌 ===


저작자 표시 비영리 변경 금지
신고
블로그 이미지

프로그래머 지향자 RosaGigantea

바쁜 일상 생활중의 기억 장소

Tag gcc, mudflat

http://www.slideshare.net/codenavy/ss-9303139


읽어보면 좋은 자료.

참고가 될듯..

저작자 표시 비영리 변경 금지
신고
블로그 이미지

프로그래머 지향자 RosaGigantea

바쁜 일상 생활중의 기억 장소

티스토리 툴바