Subject : Introduction to adb

Description :


  -----------------------
 | introduction to adb I |                    - "PANIC" chapter 7 -
  -----------------------

 UNIX "adb" command 는 가장 오래되고 가장 쉽게 얻을 수 있는 UNIX debuggers 이다.
 비록 adb 가 GUI 와 같은 특성을 갖지 못하고 source code 에 직접적인 작업을 하지
 못하더라도 아주 간단하며 UNIX gurus사이에서 kernel debugger 로 받아들여 진다.
 adb 는 kernel crashes 의 시험에만 제한되지 않으며 user program과 application
 packages 의 문제를 찾는데도 유효한 tool이다.

 'adb(absolute debugger)'라는 이름은 adb가 global symbols와 보통 hexadecimal
 인 absolute address를 다루는 사실에서 지어졌다.
 adb는 source files,line numbers,local variables,internal function label을 알지
 못하며 assembly language와 복잡하지 않은 C code에서 최적으로 작업한다.

 adb 는 단순히 이해한다면 하나 또는 두 문자 명령어로서 live system상의 process의
 실행을 제어하고 adb의 동작을 제어하며 file이나 memory의 내용을 여러가지 다른
 숫자(numerous)형식으로 display한다.
 adb는 system crashes 에 의해 만들어진 postmortem file과 live kernel의 작업에
 알맞다.

 adb는 간단하고 단순한 본성이 있는 반면 adb macor라는 강력한 기능을 제공한다.
 
 = The kernel resident absolute debugger,kadb
 
 kadb 의 특징은 UNIX kernel 대신 booting 할 수 있으며 kernel absolute debugger
 이다.
 kadb로 boot up 된 후 kernel을 load하고 실행 시킬 수 있다.
 그리고 살아 있는 상태에서 kernel을 수정하고 test할 수 있으며 breakpoints의 
 setting을 가능하게 해 준다.(주-breakpoint란 프로그램이 실행이 중단되어 시스템의
 상태,변수들의 값 또는 기억장소의 내용등과 같이 프로그램의 현재상태를 알아볼 수
 있는 지점,이러한 중단점은 프로그램의 내용을 debugging 하기위해 사용)   
 kadb도 macro facility를 가지고 있으나 adb macro 특성과 다르다. kadb에 유효한
 macro는 kadb가 실행 가능하도록 새로 만들어져야 한다.
 
 system 이 kadb 로 떨어지면, 다시말해 kadb prompt를 보게되면 모든것이 stop된다.
 더이상 윈도우를 사용할 수 있으며 background process를 수행 할 수없으며,console
 에서 kadb를 수행하고 있는 사람외엔 system에 access할 수 없다.

 = adb hardware & software requirements 
  
 adb를 사용하여 savecore files를 분석하기위해 savecore files를 같은 kernel arch.
 와 같은 operating system release를 가진 system으로 옮기는 것이 최선이고 가장
 간단한 방법이다. 물론 crashed된 시스템 자체에서도 system이 backup되고 running
 한다는 것을 가정하에 분석이 가능하다. (note- libraries,programs,directory 등의
 조작을 통해 다른 kernel arch와 OS로부터 postmortem files의 분석이가능하다.)
 system의 kernel architecture와 OS는 /usr/ucb/arch -k 또는 uname -a command로
 알아볼 수 있다.
 
 = Architecture & OS mismatched: Some adb error messages

 서로다른 kernel architecture 또는 OS로부터 kernel의 crash dump상에 adb를 시도
 하면 아래와 같은 여러가지 error messages를 보게된다.

 "Cannot adb -k: vmunix.0 : not a kernel namelist"
   SUN4/400 OS4.1.3 의 crash dump file을 SS20,solaris2.3에서 adb를 실행

 "Cannot adb -k:unix.0: can't find swapinfo"
   SUN4d system의 crash dump file을 SS20,solaris2.3에서 adb를 실행

 "Segmentation Fault - core dumped"
   SC2000,Solaris2.2 의 crash dump file을 SS20,solaris2.3에서 adb를 실행

 "Cannot adb -k: vmcore.0: uncondense error on kvtopdata : Error 0"
 "Cannot adb -k: vmcore.0: unable to read kvtopdata"
   SUN4m,2.3 system의 crash dump file을 SUN4m,2.2에서 adb를 실행

 "Cannot adb -k: cannot mmap vmcore.0's bitmap: Invalid argument"
   sun4d 2.3 crash를 sun4 4.1.3에서 adb를 실행

 마지막으로 kernel arch와 OS가 잘 match된 경우가 아래에 있다.
  ____________________________________________________________
 |                                                            |
 |   system# adb -k unix9 vmcore.9                            |
 |   physmem fd87                                             |
 |____________________________________________________________|   

 위 성공적인 예에서 보듯 adb는 memory의 pages 의 숫자를 display 한 후
 우리의 첫번째 command를 기다린다.

 = The distribution of adb
 
 adb program은 solaris 1.x systems 의 debugging group의 일부분에 속해있다.
 Solaris 2 systems에서는 adb는 보다 module화 되어 4개의 packages 에 분산
 되어 있다.(man page는 제외)
 @ SUNWcar : kadb found
 @ SUNWkvm : adb & adb macros
 @ SUNWtoo : adb 가 /usr/bin에 link되며 savecore와 strings program을 포함
 @ SUNWesu : adbgen utility 를 포함 adbgen 은 프로그래머가 adb macros를
             만들 수 있게 도와주는 utility이다.
 
 = The different uses of adb & kadb
 
  core 를 dump시킨 user program을 살펴 보거나 crash가 발생한 postmortem
  file을 시험하기 위해서 adb를 사용하려면 object file과 core file을 함께
  사용하여야 한다.

 - The object file

  실행 가능한 object file은 program이나 kernel이 될 수 있는데 이 file은
 symbol table과 실행가능한 code를 담고 있다.symbol table은 필요하지는
 않지만 그것이 없으면 adb의 symbolic 특성을 사용할 수 없다.
 default object file은 a.out이다.

 symbol table은 adb 또는 다른 debugger가 symbolic name과 real address를
 matching 할 수 있게 한다.adb가 전혀 관심이 없더라도  hexadecimal
 address 보다 변수나 function들이 이름을 가지는 편이 사림들에게 보다나은 
 반응을 줄 것이다.
 
 - The core file

  kernel이나 program의 postmortem 분석에서 실패가 일어난  순간에  
 kernel이나 프로그램에 의해 사용된 memory 의 sanpshot을 나타내는
 image file이 core file 이며 default는 core이다.
 live system 이 보여질때는 core file은 kernel에 의해 현재 사용되는 memory의
 반영이다.

 만약 어떤 이유로든 object file과 core file 중 하나라도 없는 경우 adb를 
 일으켰을때 command line 상의 자리에 dash "-"를 명시할 수 있다.
 
 - Using adb on crash dumps

 core file은 error의 원인과 위치를 규정하기 위해 실행 file 과 함께 시험될 수
 있으며 adb가 assembly code 와 함께 작업하기 때문에 프로그램의 source code가
 없더라도 많은 작업을 할 수 있다.
 
 savecore files 은 physical memory 의 전체내용이 아니더라도 보통 모든 kernel
 data space를 포함한다.
 adb -k flag 는 crash dump savecore files 이나 live system의 분석에 사용된다.
 왜냐면 adb는 kernel data space 에 대한 많은 address translation 작업이 많이
 필요하기 때문이다.(주-  -k flag는 kernel memory mapping을 수행;system crash
 dump 또는 /dev/mem,또는 sapfile을 사용할 때 사용)
 
 - Using adb on live systems
 
 adb는 postmortem files만 debugging 되는 것이 아니다.
 adb는 보다 나은 performance를 얻기 위해서 running system을 수정하거나 조정할
 수 있다.
 adb는 또한 system의 behavior를 차기 boot 시에 바꾸기 위해서 klernel을 수정하
 는데도 사용할 수 있다.
 default로 adb는 object와 core file를 읽거나 볼 수 밖엔 없다.
 그러나 adb를 일으킬 때 -w flag를 쓰거나 adb에서 $W command를 쓰면 write할 수
 있다.
 
 - The kernel resident absolute debugger,kadb
 
 live system을 debug할 위치에 있다면 kadb를 사용할 수 있다.
 kadb는 operating system대신에 debugger로 초기booting하여 kernel의 나머지를
 load하거나 start시킬 수 있도록 만들어져 있다.
 어떤것이 panic을 일으켰을때 system이 죽는 상황에서 kadb는 system을 접수하고
 얼마간 system을 떠날 수 있다. 이 시점이 kadb 가 우리와 함께 일 할 준비가 된
 것이다.
 kadb의 대화적 특성은 주요한 이점이다. 
 kadb를 사용하여 kernel의 breakpoint를 설정해서 마치 커다란 user program과 같이
 단계적으로 실행시키고 values를 수정하여 test할 수 있다. 
 adb를 사용하여 postmortem files를 다룰때는 위와같은 level의 interaction은 준비
 되지 않는다.
 
 - adb macros & /usr/lib/adb
 
 비록 adb가 매우 제한된 명령어의 sets을 가지고 있지만 macros로 알려진 상당히
 강력한 명령어의 combinations 을 가지고있다.
 adb macros는 common commands의 set을 만들고 저장하고 invoke할 수 있게하며
 다른 macro를 call할 수 있게 design되어 졌고 최소의 노력으로 강력한 분석을 
 가능케 한다.
 많은 수의 macro files가 solaris 1에서 /usr/lib/adb 안에 준비되어 있다.
 Solaris 2 system은 /usr/kvm/lib/adb 에서 adb macros를 찾을 수 있다.
 대부분의 macros는 SUN에 의해 준비되어 kernel으로부터 통상적으로 필요한 구조를
 읽기쉬운 형식으로 print out 하는데 사용된다. 
 
 - General startup syntax
 
  -------------------------
 | adb objectfile corefile |
  -------------------------
 
 - User program debugging
 
   ----------------
  | adb a.out core |
   ----------------
   -----------------
  | adb myprogram - |
   -----------------
 user program을 시험하기위해 adb를 invoking 할때의 syntax는 위와같다.
 만약 core file이 명시되지 않으면, adb는 현재 directory의 core file을
 찾는다.
 core file대신 "-"(dash)가 명시되면 adb는 object file을 실행하기위해
 system memory를 사용한다. 이와같은 사용법은 추후 "Symbol Tables"에서
 살펴보자.
 executable image 안에 symbol table 이 없으면 adb는 변수 또는 function
 들을 이름에 의해 명시할 수 없다.
 이경우 error의 위치를 찾기가 극단적으로 어렵다.
 만약 stack traceback 또는 memory 의 시험에서 reports가 오직 hexadecimal
 로 되어 있으면 object file로 부터 symbol table이 제거된 상태가 아닌지
 check 해보아야 한다.
 symbol table의 제거는 UNIX strip command로 가능하지만 한번제거된
 symbol table은 복구가 불가능 하다.
 
 - Examining system crash dump postmortem files
 
   --------------------------
  |  adb -k unix.X vmcore.X  |
   --------------------------
 Solaris 1 system 에서는 object file은 vmunix.X 이며 여기기서 X는 savecore
 program이 할당한 crash number이다.
 Solaris 2 system에서는 object file은 unix.X라 불리며 여기서의 X도 savecore
 에 의해 할당된 crash number이다.
 
 - Examining a live system:Solaris 1
 
   --------------------------
  |  adb -k /vmunix /dev/mem |
   --------------------------
 
 여기엔 crash file 이 없으며 object file 은 booting되고 실제적인 실행 kernel
 인 /vmunix 이다. core file 인 /dev/mem 은 현재의 physical memory의 내용이다.
 
 /dev directory 에는 두개의 memory file이 있다.
 /dev/mem , /dev/kmem 이 그것이며 서로다른 목적으로 adb와 함께 오직 한가지만
 쓰인다.
 /dev/kmem device file은 현재 running kernel 에 대한 "kernel virtual memory"
 로서 kernel space의 virtual address 만 받아들인다.
 /dev/mem device file은 actual physical memory에 대응된다.
 
 adb가 physical memory pages의 copy로 부터 만들어진 core file을 찾도록 되어
 졌기 때문에 data 를 위치하기 위해서 내부적으로 physical 에서 virtual address
 translations를 자동으로 수행한다.그러므로 physical memory에 대응되는 file을
 adb 에게 제공해야 한다.
 
 - Examining a live system:Solaris 2
 
   -----------------------------
  |  adb -k /dev/ksyms /dev/mem |
   -----------------------------
 Solaris 2 system은 kernel level에서 Solaris 1 system과 매우다르다.
 kernel 은 보다 module화 되어 다양한 조각으로 memory로 적재되며 그것이 꼭
 같은 directory 같은 file에서 올 필요가 없다.
 
 /kernel/unix 는 Solaris 1 의 /vmunix file과 가장 비슷한 것으로 전과달리
 system의 heart또는 "core" 이며 다른 loadable module이나 device에 대한 
 symbol은 포함하지 않는다.   
 새로운 pseudo-device /dev/ksyms 는 system에 현재 적재된 모든 module의 symbol
 table 에 대응된다.
 또한 /dev/ksyms device 가 open 되었을때 적재되지않은 module로 부터 module을
 보호한다. 이것은 우리가 analyze 하는 동안 symbol table을 보증해준다.
 그러나 module이 요구에 의해 적재된 이후로 우리가 여기저기 뒤지는 가운데 이전에
 요구되지 않은 sections 를 disk로부터 가져옴에 따라 kernel은 계속 size가 커질
 것이다. 그래서 새로운 symbols이 더해질 것이나 /dev/ksyms 가 open 되어 있는동안
 에전것은 사라지지 않을 것이다.
 
 = Security issues
 
 Solaris 1 system에서는 group 2 ( /etc/group file에 kmem group ) 에 추가되어진
 nonroot user는 running kernel에 adb를 사용할 수 있으나, Solaris 2 system에선
 kernel을 수정하고 검사할 수 있도록 허가된 nonroot user는 없다.
 
   

Revision History

작성일자 : 
작성자 : 

수정일자 : 
수정자 :