[리눅스 개발환경] 03. GDB 디버깅

[tonykang22]

03. GDB 디버깅

GDB 디버깅 개요

• 보통은 GDB라고 부르는 GNU 디버거는 GNU 소프트웨어 시스템을 위한 기본 디버거이다.
• GDBS는 다양한 유닉스 기반의 시스템에서 동작하는 이식성있는 디버거로, 에이다, C, C++, 포트란 등의 여러 프로그래밍 언어를 지원한다.

특징

• 프로그램을 줄 단위로 실행하거나 특정 지점에서 멈추도록 할 수 있다.
• 프로그램 수행 중간에 각각의 변수에 어떤 값이 할당되어 있는지 확인할 수 있다.
• 원하는 값을 변수에 할당 후 어떤 일이 벌어지는지 확인할 수 있다.

참고 사항

• 프로그램 바이너리가 gdb로 디버깅 가능하려면 컴파일 시 -g 옵션을 통하여 디버깅 정보가 추가되어야 한다.
  • ex) gcc -g hello.c -o hello

GDB로 할 수 있는 일

• 정지점(Break Point) 설정
  • 지정한 지정(정지점)에서 프로그램 실행을 일시적으로 중단할 수 있다. 정지점에서 프로그램을 중단한 뒤 특정 값을 표시해 이 값이 옳은지 판단할 수 있다. 정지점은 조건적으로 설정할 수도 있다.
    • 예) # (gdb) condition 1 low==high
• 하드웨어 감시점
  • 일부 프로세서에서는 하드웨어를 사용하여 특정 메모리 값이 변하는지 감시할 수 있다. 예를들어 하위메모리 전역 변수 TheMem이 변하는 순간을 알고 싶다면
    • 예) # (gdb) watch TheMem
    • Hardware watchpoint 1: TheMem
    • (gdb) c
    • Continuing.
    • Hardware watchpoint 1 : TheMem
    • Old value = 0
    • New value = 768
    • C_FirstMenu (mid=3) at menu1.c:577
• 프로그램 값과 속성 표시
  • 프로그램을 실행하면서 gdb 명령으로 현재 변수 값을 표시할 수 있다.
• 프로그램 단계별 수행
  • 실행 프로그램의 각 행을 한 번에 하나씩 실행할 수 있다.
• 스택 프레임
  • 프로그램에서 함수를 호출할 때마다, 호출 관련 정보가 스택 프레임(stack frame) 또는 프레임(frame)이라는 자료 블록에 저장된다.
  • 함수 호출 하나당 프레임은 하나이며, 프레임에는 함수에 주어진 매개변수, 함수의 지역 변수,함수 실행 주소 등이 들어있다.
  • 모든 스택 프레임은 콜 스택(call stack)이라는 메모리 영역에 할당한다.
  • 프레임을 조작하는 기본 명령에는 frame, info frame, backtrace가 있다.

GDB 기본 사용법

• 컴파일 시 –g 옵션을 이용하여 만들어진 프로그램(실행파일)을 인자로 gdb를 실행하면 디버깅이 시작된다.
  • ex) # gdb TestProgram
• 만약 TestProgram을 실행하다가 core dump가 발생하면 core 파일과 함께 gdb를 실행한다.
  • ex) # gdb TestProgram core
• gdb는 현재 실행중인 프로세스에 대해서도 디버깅 작업을 수행할 수 있다.
  • 프로세스 ID를 인자로 gdb를 수행하면 된다. 예를 들어 PID가 1234 일 경우
  • ex) # gdb TestProgram 1234

코어 덤프

• 코어 덤프(core dump)는 컴퓨터 프로그램이 특정 시점에 작업 중이던 메모리 상태를 기록한 것으로, 보통 프로그램이 비정상적으로 종료했을 때 만들어진다.
• 실제로는, 그 외에 중요한 프로그램 상태도 같이 기록되곤 하는데, 프로그램 카운터, 스택 포인터 등 CPU 레지스터나, 메모리 관리 정보, 그 외 프로세서 및 운영 체제 플래그 및 정보 등이 포함된다.
• 코어 덤프는 프로그램 오류 진단과 디버깅에 쓰인다.
• 사용자 응용 프로그램이 문제가 생겼을 경우 코어(core) 파일을 생성할 수 있으려면, 시스템에서 제한하는 코어 파일 크기가 0보다 커야 한다.
• 코어 파일 크기가 0이면, 시스템은 코어 덤프(core dump)를 허용하지 않는다.
• ulimit –a 명령으로 코어 파일 크기를 확인할 수 있고, ulimit –c 명령으로 코어 파일 크기를 변경할 수 있다.
• 코어 파일 생성 위치 확인
  • [root@localhost systemd]# cat /proc/sys/kernel/core_pattern
  • |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %e
  • CentOS의 경우 상기와 같이 core_pattern의 첫 문자가 파이프(|)일 경우 systemd로 리다이렉션한다.
• 코어 덤프 파일 실습을 위하여 특정 위치(일반적으로 /var/crash)에 코어 덤프가 생성되도록 수정해보기 *# vi /etc/sysctl.conf
  • kernel.core_pattern = /var/crash/core.%e.%p.%h.%t
    • %e – executable filename.
    • %p – PID of dumped process.
    • %t – time of dump (seconds since 0:00h, 1 Jan 1970).
    • %h – hostname (same as ’nodename’ returned by uname(2)).
  • fs.suid_dumpable = 2
    • 2(suidsafe) – 일반적으로 모든 바이너리는 루트만 읽을 수 있도록 덤프된다.
    • 이를 통해 최종 사용자는 그 덤프를 제거할 수 있지만 직접 액세스 할 수 없다.
    • 보안상의 이유로 이 모드의 코어 덤프는 서로 또는 다른 파일을 덮어 쓰지 않으며, 이 모드는 관리자가 일반 환경에서 문제를 디버그하려고 할 때 적합하다.
• 설정 재로딩
  • # sysctl -p

GDB 명령

GDB 실습 1

• GDB를 사용하기 위해 gdb_test1.c 파일 생성

• 실행 시 Segmentation fault (core dumped) 메세지를 확인할 수 있다.

• ~ at gdb_test1.c:4와 같이 문제 발생 시 자동으로 중단되며 정보 출력이 쉽게 확인된다.

GDB 실습 2

• 코드의 의도는 number 변수에 “1234” 문자열이 들어있고, atoi()를 통해 숫자 1234로 변환한 결과를 출력하고자 하는 의도라고 가정하자.
  • 그러나 "abcd"가 담긴 상황

    // main.c
    #include <stdio.h>
    #include <stdlib.h> /* for atoi() */
    void func1(void); void func2(void);
    int main()
    {
    int result;
    char number[] = "abcd";
    printf("main() start\n");
    func1(); func2();
    result = atoi(number); printf("result: %d\n", result);
    return 0; }

// func1.c
#include <stdio.h>
void func1()
{
printf("func1 called\n");
}

#include <stdio.h>
void func2()
{
printf("func2 called\n");
}

• 하지만 result 출력 0

• main.c 파일의 첫 수행에 break point 지정
• main() 함수 속 변수 선언 이후 첫 문장(10번째 줄)에 지정

• run을 통해 실행해보면, Breakpoint 1을 통해 main.c의 7번째 줄에서 멈췄다.

• next 실행 시, 함수 안으로 진입하지 않고 넘어간다.

• step 실행 시, 함수 안으로 진입하는 것을 확인할 수 있다.

• display result / number 를 통해 현재 시점의 result와 number 변수 값 출력이 가능하다.

• result 가 정의되지 않은 시점에서 display result 호출 시 화면

• set 명령을 통해 변수에 의도한 값을 넣어볼 수도 있다.
• 실제 코드를 수정 후, 컴파일 하지 않고 수정된 값으로 변경 후 gdb 프로그램을 계속 실행할 수 있다.