Linux Debugging issues

Presentation on theme: "Linux Debugging issues"— Presentation transcript:

1 Linux Debugging issues
MDS technology

2 Second Annual ESC Survey Results
As promised on our last newsletter, Virtutech released the results of its second annual Embedded Systems Conference survey in May. Virtutech surveyed a cross-section of attendees to get feedback on the most time-consuming phase in the software development life cycle, with specific questions targeted at debugging for multi-core processors. Not surprisingly, 63 percent of respondents indicated that debugging continues to be the most time-consuming and costly phase of the software development life cycle, almost double any other single task. Furthermore, the survey highlighted the growth of multi-core processing and the need for innovative debugging technology to meet the consequent challenges. Respondents listed the most challenging aspects of debugging software on multiprocessor systems as thread locking (31 percent), lack of determinism/bug reproducibility (30 percent) and the fact that breakpoints do not freeze the system (29 percent). However, over one-half of respondents are using debuggers that do not support multiprocessor development

3 Linux Features 주소 공간 실행 주소 실행 방법 Kernel 물리적인 주소와 논리적인 주소가 동일
UNIX-like Linux는 ‘Open source를 이용해서 상용 RTOS에 비해 개발비용을 현저하게 줄여준다’ 고 한다.(이 말에는 함정이 있다. 상용 RTOS의 License 비용은 줄일 수 있지만 Linux 개발에는 그 어느 누구도 결과물에 대한 안정성을 보장해 주지 않고, 끊이지 않는 License 논란과 위협에 직면할 수 있다) Linux는 메모리 공간들을 보호하기 위하여 MMU를 사용하는데 아이러니컬하게 이 MMU는 디버깅을 아주 어렵게 만드는 원인이 된다. 때문에 Linux 커널, LKM (Loadable Kernel Module) 그리고 application에 따라서 서로 다른 디버깅 방법을 이용해야 한다. (LKM의 예로 device driver가 있다) 주소 공간 실행 주소 실행 방법 Kernel 물리적인 주소와 논리적인 주소가 동일 Linking에서 결정 ROM이나 ICE에 의한 특정 주소에서 LKM insmod 명령으로 Kernel의 File system에서 수행 Applications Virtual address

4 Linux Features (cont’)
Kernel 실행 주소가 linking 에서 결정되고 실행되는 logical address는 physical address와 일치하기 때문에 디버깅이 쉽다. 하지만, kernel source code만 따라가는 기능 외에 TRACE32는 Kernel의 내부 정보를 읽을 수 있기 때문에 task나 memory 사용률 등의 핵심적인 정보를 이용할 수 있다. LKM 실행되는 logical address는 kernel과 같은 메모리 공간에서 수행되지만 insmod로 loading되는 주소는 실제 실행 시에 결정된다. Kernel로부터 실제 loading되는 주소를 찾지 못하면 엉뚱한 결과를 초래할 수 있다. TRACE32는 커널에서 정확한 주소 정보를 얻어올 수 있다. Applications 각 application들은 physical address와 다른 독립적인 virtual address를 가지고 수행되기 때문에 각 task의 정확한 주소 정보를 알아야 debugging이 가능하다.

5 Problems of GDB GDB는 Linux 개발자들이 최고의 디버거라고 오해하고 있는 software 방식의 debugger. (ptrace라는 내부 함수 이용) Ethernet 등을 이용한 high speed communication 지원한다? 하지만 Ethernet을 이용한다면 Ethernet interface와 덩치 큰 network stack을 항상 갖춰야 한다. Not-Unified debugging gdb는 target에 gdb server가 올라온 이후 통신이 가능 반드시 Linux kernel이 target에 먼저 porting이 끝난 이후에야 이용 가능. Boot loader와 Kernel, LKM은 debugging하지 않을 것인가 ? Difficulty in real-time debugging(not Real-time of PowerTrace) Kernel debugger와 PC가 통신을 할 때는 interrupt를 막기 때문에 실제 환경과 다를 수 있고, debug server가 break를 걸려 해도 kernel이나 LKM은 바로 멈추지 않을 수 있다. 디버깅 중인 현 task와 무관하게 CPU가 동작하기 때문에 CPU의 정확한 context를 볼 수 없다.

6 Problems of GDB (cont’)
No high-level debugging features Hardware breakpoints and event trigger Fast program download Running 중인 application task 정보 외의 kernel resource나 다른 task의 정보를 얻기 힘들다. Target이 reset등의 exception이 발생했을 경우, GDB 자체를 이용할 수가 없다. GDB의 타겟을 멈추지 않고 내부 동작상태를 확인할 수 있는 run-mode debugging 기능은, TRACE32에서 지원 예정 (10월 초)

7 Powerful TRACE32 for Linux
GDB/DDD agent/server를 올리는 overhead가 없다. TRACE32는 부트로더부터 multi-thread 환경까지 하나의 장비로 디버깅이 가능하다. Target의 CPU를 직접 control하여 task 간의 Real-time debugging이 가능하다. Multi-thread 뿐만 아니라 multi-process 환경까지 완벽하게 지원한다. High-speed image download Linux Kernel Awareness는 사용자가 kernel 내부를 잘 몰라도 디버깅에 필요한 많은 정보를 제시해 준다. 강력한 breakpoint, CTS, code coverage 기능과 Performance monitoring 기능으로 기본적인 source level debugging 이상의 환경을 제공

8 IMO Hardware Specifications CPU: S3C2410x (ARM920T)
64MB SDRAM (0x x4FFFFFF) 4MB NOR Flash (0x0++0x3FFFFF) 32MB NAND Flash

9 Binary Format Binary Format? Binary Code EA000125 EA00005D B 0x49C
Address, 심볼, Check sum 등의 정보를 포함하지 않고 순수하게 실행할 수 있는 코드만 포함 Disassembly Binary Code EA000125 EA00005D EA000062 EA00006D B 0x49C B 0x180 B 0x198 B 0x1C8 END

10 ELF Format Header Part Binary Part Symbol Part
Executable and Linkable Format UNIX System Laboratory에서 Application Binary Interface (ABI)의 일부로서 개발되고 발표 Tool Interface Standards committee (TIS)에서 32 bit Intel Architecture 환경에서 동작하는 portable object 파일 포맷 표준으로 선택 Binary에 대한 Relocation 가능 Dynamic loading 가능 Symbol 정보를 이용해서 Debugging 가능 Header Part Binary Part Symbol Part ELF Format의 논리적 구조

11 TRACE32를 이용한 다운로드 2 ARM 7,9,10 CORE ICD FLASH RAM Phone.elf HOST PC
B::Data.LOAD.ELF Phone.ELF ICD 1 Phone.elf 중 Binary part ARM 7,9,10 CORE FLASH FLASH 2 Phone.elf 중 Symbol Part ARM CORE Trace32 RAM Symbol Phone.elf Binary SRAM HOST PC TARGET PHONE