검색결과 리스트
debuging tool에 해당되는 글 1건
- 2008.11.27 adb 사용법
글
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.
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된 경우가 아래에 있다.
____________________________________________________________
howtosolaris# 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는 없다
비록 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된 경우가 아래에 있다.
____________________________________________________________
howtosolaris# 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는 없다
RECENT COMMENT