Recommended Taste, Share and Have Fun: An Experiment in Procedural Rhetoric
Urustar - Company Profile (Jan 2013)
Central Lechera Asturiana by CUENTO
Zwan - The Making of a Bosch Art Game Finalist
Processing 기초 이해하기_20160713
A tour of C++ : the basics
임베디드 시스템 설계 프로젝트: EMPOS-II를 활용한 영어단어 학습기
2 1. variables & data types
01. Computer System Basics with C Language
Linux reversing study_basic_3
Debugging with visual studio. 비주얼 스튜디오를 활용한 디버깅
[Kerference] 시작! 리버싱 - 김종범(KERT)
More Related Content Taste, Share and Have Fun: An Experiment in Procedural Rhetoric
Urustar - Company Profile (Jan 2013)
Central Lechera Asturiana by CUENTO
Zwan - The Making of a Bosch Art Game Finalist
Similar to The Architecture of Open Source Applications : GDB (20)
Processing 기초 이해하기_20160713
A tour of C++ : the basics
임베디드 시스템 설계 프로젝트: EMPOS-II를 활용한 영어단어 학습기
2 1. variables & data types
01. Computer System Basics with C Language
Linux reversing study_basic_3
Debugging with visual studio. 비주얼 스튜디오를 활용한 디버깅
[Kerference] 시작! 리버싱 - 김종범(KERT)
The Architecture of Open Source Applications : GDB10. 구조
• 심볼사이드
• 타겟사이드
• 인터페이스
• 개발프로세스
• 교훈
16. 구조
• 심볼사이드
• 타겟사이드
• 인터페이스
• 개발프로세스
• 교훈
18. 소개
• GNU Debugger
• GNU(GNU is not Unix) = OS
• GCC, Emacs, ...
• Richard Stallman
24. 구조
• 심볼사이드
• 타겟사이드
• 인터페이스
• 개발프로세스
• 교훈
34. 구조
• 심볼사이드
• 타겟사이드
• 인터페이스
• 개발프로세스
• 교훈
39. Side
• start and stop the program
• read memory and registers
• modify them
• catch signals
43. Side
• independent
• read code, display variables
without running the program
• machine-language debugging
without symbols
52. 구조
• 심볼사이드
• 타겟사이드
• 인터페이스
• 개발프로세스
• 교훈
53. Operation
• print int-type variable
• 1. command interpreter (tree traversal)
• 2. find variable address (symbol table)
• 3. call target-side function(read 4-byte)
• 4. formatting function(decimal number)
62. 구조
• 심볼사이드
• 타겟사이드
• 인터페이스
• 개발프로세스
• 교훈
67. Breakpoints
• 유저에게 노출되고 조작되는 구조체
• break 명령으로 생성, location 설정
• location = function name, line number,
memory address
• 결국은 주소값으로 계산됨
68. Breakpoints
• 원래 형태도 보관(재컴파일, 리로딩)
• 한 location이 여러곳을 가리킬 수 있음
• inline function, template methods
74. Tables
• LARGE (up to gigabytes of RAM)
• Major performance bottle-neck
• string -- address map
77. Stackframes
• push program counter(PC) to stack
with arguments
• vary from chip architecture, OS,
compiler, optimization options
78. Stackframes
• [stack frame to new chip] == BIG JOB!
• buggy programs, incomplete frames,
can stop anywhere, highly optimized
programs
81. Expressions
• Build Tree structure (of node objects)
• node object = union
- support different languages
• ex) Fortran var. - C var.
84. Values
• Even value is structure
• Various properties
• r-value, l-value
• bool - constructed lazily
92. 구조
• 심볼사이드
• 타겟사이드
• 인터페이스
• 개발프로세스
• 교훈
96. Side
• BFD (Binary File Descriptor)
universal library - handle exe obj file
• 1. COFF (Common Object file format)
System V Unix, MS Windows
• 2. ELF(Executable and Linkable Format)
Unix, Linux, embedded systems
108. 구조
• 심볼사이드
• 타겟사이드
• 인터페이스
• 개발프로세스
• 교훈
110. Side
• Manipulation of program execution
raw data
• step instructions
• dump raw memory
- no need symbol data
112. Side
• Target Vector
• target vector, which is basically a class
of objects
• each defines the specifics of a type of
target system
116. Side
• Target can be changed
• target vector get variable from exe file
before program run
• target vector get variable from memory
after program run
124. Side
• The Remote Protocol
• designed for embedded systems
• protocol is simple.
134. 구조
• 심볼사이드
• 타겟사이드
• 인터페이스
• 개발프로세스
• 교훈
135. Interfaces
• 1. Command Line Interface
- Use GNU library [readline]
• interpret) “command option...”
- command table, expression
145. 구조
• 심볼사이드
• 타겟사이드
• 인터페이스
• 개발프로세스
• 교훈
166. 프로세스
• Test suite
- Highly system specific
• DejaGNU - testing framework
• Send command - pattern matching the
output (regular expressions)
168. 프로세스
• 18,000 test cases
• No one has access to all platform
(that might be affected by a change)
• 10-20 failures OK.
176. 구조
• 심볼사이드
• 타겟사이드
• 인터페이스
• 개발프로세스
• 교훈
177. 교훈
• Open Development Wins
• Make a Plan, but Expect It to Change
• Don't Get Too Attached to the Code
Editor's Notes #2: \n #3: \n #4: \n #5: 원래 GNU Debugger 였음.\nGNU's Not Unix의 약자. 유닉스(Unix)의 상업적 확산에 반발하여 리처드 스톨먼과 그의 팀이 무료로 개발·배포하고 있는 유닉스 호환 운영 체제.\n1985~1988년에 GCC, Emacs 와 함께 개발된 초기 소프트웨어 중 하나.\n\n\n #6: \n #7: 유저와 소통 가능, 컴파일러는 깐깐한데 비해 GDB는 타입 등에 너그러움, 50~100MB부터 1GB 실행파일까지 요청됨. 임베디드, 32-64bit, 각종 OS 등등...\n\n #8: \n #9: [CLI] - command line interface [MI] - Machine interface [BFD] - Binary File Descriptor [COFF] - Common Object file format [ELF DWARF] - Executable and Linkable Format Debugging With Attributed Record Formats\n #10: \n #11: \n #12: 타겟 시스템마다 위에 설명한 액션들의 방식이 다 다르다. unix system에선 ptrace가 이것들을 해줌. GDB는 이를 활용. 주로 하는일이 ptrace 콜. \n #13: \n #14: \n #15: \n #16: 1. Interface level, 2. symbol side, 3. target side, 4. Interface\n #17: PC - 다음 실행할 명령의 주소를 가지고 있음. 이것과 다음 라인의 주소를 비교. \n #18: GDB의 여러가지 데이터 구조를 살펴보겠음.\n #19: \n #20: \n #21: \n #22: \n #23: \n #24: 온갖 함수, 전역변수, 로컬변수, 헤더 디파인 된 것들 등... (파일 읽기가 아니라 구성하는데 시간이 오래걸린다) 뒤에 퍼포먼스를 어떻게 해결하는지 나옴.\n #25: \n #26: \n #27: \n #28: \n #29: 각 언어들간에 표현식의 문맥은 동일하므로 문맥 트리 구조 구성. 각 노드는 유니언. 포트란 변수 - C언어 변수 빼는것도 가능.\n #30: \n #31: lazy construction - c는 함수 시작에 다 선언, c++은 필요할때 선언. 람다에도 뭐가 있는거 같던데... \n #32: \n #33: \n #34: 1. BFD library. 2. COFF는 specification 임. 3. ELF도 spec.\n #35: 큰 실행파일도 몇초만에 실행은 일단 할 수 있고 프로그램이 진행되면서 필요한 심볼을 읽어들인다.\n #36: yacc (yet another compiler compiler) - 구문 분석 테이블 생성을 위해 사용되는 소프트웨어. 입력된 구문을 분석하여 구문분석 트리를 자동으로 생성해주는 코드 생성. Lex - 토큰 분석을 해주는 코드 생성기.\n #37: print $a 하면 그냥 알맞는 타입으로 변수 출력 등..\n #38: \n #39: \n #40: TargetSide는 또 여러 부분으로 나뉘는데, 그 중 하나가 TargetVector. Vector = 매개체, 진로\n #41: \n #42: \n #43: \n #44: 아키텍처마다(온갖 종류와 32, 64bit 등등) 내부 동작이 모두 다르므로 여러 아키텍처를 관리해야 함. 옛날엔 프리프로세서 (#define) 지금은 Gdbarch.\n #45: 아까 설명했던 한줄 지나가는데 여러단계가 필요하기 때문에 기다리는 명령. continue, step명령을 내리면 잠시 느린데 이건 아무거도 안하는게 아니라 내부적으론 바쁘게 돌고 있다. \n #46: 이건 간단하고 문서화도 잘 되어있어서 누구나 구현할 수 있고 새로 싹 작성하기 때문에 GNU라이센스를 따르지 않아도 된다. \n #47: Remote Protocol packet을 받기 담당. 그림을 보면 알 수 있듯이 GDB와 GDBserver가 하는 일은 비슷함. mini GDB라고 함. 내부 소스를 많이 공유.\n #48: \n #49: readline - 콘솔에서 많이 사용하는거. 커서로 위아래로 명령 저장 실행 등. command는 command table에서 찾고 나머지는 표현식 해석...\n이미지는 Command line interface가 어떻게 생겼다... 보여만 주는것\n #50: \n #51: \n #52: \n #53: \n #54: \n #55: \n #56: \n #57: 2. 오픈소스 개발은 대 혼란이다. 계획은 세우되 개발자들을 시간&날짜로 압박주면 안된다. 계획은 바뀔 수 있고 더 좋은 방법들이 나올 수 있다. 2. 어떤 시스템-스페시픽 기술에 힘을 쏟았는데 금방 다른 시스템들이 많이 생겨났고 쓸모없는 기술이 되었다. 한곳에 너무 집중하지 말고 상황이 바뀔것을 항상 예상하자. \n #58: \n