1. 소스 파일은 오브젝트 파일로 컴파일됩니다.
2. 오브젝트 파일과 라이브러리가 연결되어 있습니다(이전 컴파일된 소스 포함).

절차

1. 소스 코드 파일이 포함된 디렉터리로 변경합니다.

2. c 옵션을 사용하여 gcc 를 실행합니다.

   $ gcc -c source.c another_source.c

   개체 파일은 원본 소스 코드 파일을 반영하는 파일 이름을 사용하여 생성됩니다 . source.c 는 source.o 가 됩니다.

   참고

   C++ 소스 코드로 gcc 명령을 g++로 교체하여 C++ 표준 라이브러리 종속성을 편리하게 처리하십시오.

절차

1. 개체 코드 파일이 포함된 디렉터리로 변경합니다.

2. gcc 실행 :

   $ gcc ... objfile.o another_object.o ... -o executable-file

   executable-file이라는 실행 가능한 파일은 제공된 오브젝트 파일 및 라이브러리에서 생성됩니다.

   추가 라이브러리를 연결하려면 오브젝트 파일 목록 뒤에 필요한 옵션을 추가합니다.

   참고

   C++ 소스 코드로 gcc 명령을 g++로 교체하여 C++ 표준 라이브러리 종속성을 편리하게 처리하십시오.

절차

1. hello-c 디렉터리를 생성하고 변경합니다.

   $ mkdir hello-c
   $ cd hello-c

2. 다음 콘텐츠를 사용하여 hello.c 파일을 생성합니다.

   #include <stdio.h>
   
   int main() {
     printf("Hello, World!\n");
     return 0;
   }

3. GCC로 코드를 컴파일하고 연결합니다.

   $ gcc hello.c -o helloworld

   이렇게 하면 코드가 컴파일되고, 오브젝트 파일 hello.o 를 생성하고, 오브젝트 파일에서 실행 파일 helloworld 를 연결합니다.

4. 결과 실행 파일을 실행합니다.

   $ ./helloworld
   Hello, World!

절차

1. hello-c 디렉터리를 생성하고 변경합니다.

   $ mkdir hello-c
   $ cd hello-c

2. 다음 콘텐츠를 사용하여 hello.c 파일을 생성합니다.

   #include <stdio.h>
   
   int main() {
     printf("Hello, World!\n");
     return 0;
   }

3. GCC를 사용하여 코드를 컴파일하십시오.

   $ gcc -c hello.c

   오브젝트 파일 hello.o 가 생성됩니다.

4. 오브젝트 파일에서 실행 가능한 파일 helloworld 를 연결합니다.

   $ gcc hello.o -o helloworld

5. 결과 실행 파일을 실행합니다.

   $ ./helloworld
   Hello, World!

절차

1. hello-cpp 디렉터리를 생성하고 변경합니다.

   $ mkdir hello-cpp
   $ cd hello-cpp

2. 다음 콘텐츠를 사용하여 hello.cpp 파일을 생성합니다.

   #include <iostream>
   
   int main() {
     std::cout << "Hello, World!\n";
     return 0;
   }

3. 코드를 컴파일하고 g++ 로 연결 :

   $ g++ hello.cpp -o helloworld

   이렇게 하면 코드가 컴파일되고, 오브젝트 파일 hello.o 를 생성하고, 오브젝트 파일에서 실행 파일 helloworld 를 연결합니다.

4. 결과 실행 파일을 실행합니다.

   $ ./helloworld
   Hello, World!

절차

1. hello-cpp 디렉터리를 생성하고 변경합니다.

   $ mkdir hello-cpp
   $ cd hello-cpp

2. 다음 콘텐츠를 사용하여 hello.cpp 파일을 생성합니다.

   #include <iostream>
   
   int main() {
     std::cout << "Hello, World!\n";
     return 0;
   }

3. g++ 로 코드를 컴파일하십시오.

   $ g++ -c hello.cpp

   오브젝트 파일 hello.o 가 생성됩니다.

4. 오브젝트 파일에서 실행 가능한 파일 helloworld 를 연결합니다.

   $ g++ hello.o -o helloworld

5. 결과 실행 파일을 실행합니다.

   $ ./helloworld
   Hello, World!

1. 코드가 포함된 디렉터리로 변경합니다.

2. foo 라이브러리의 헤더를 사용하여 프로그램 소스 파일을 컴파일합니다.

   $ gcc ... -Iheader_path -c ...

   header_path 를 foo 라이브러리의 헤더 파일이 포함된 디렉터리의 경로로 바꿉니다.

3. foo 라이브러리와 프로그램을 연결합니다.

   $ gcc ... -Llibrary_path -lfoo ...

   library_path 를 libfoo.a 파일이 포함된 디렉터리 경로로 바꿉니다.

4. 나중에 프로그램을 실행하려면 다음을 수행하십시오.

   $ ./program

절차

1. 라이브러리 소스를 사용하여 디렉터리로 변경합니다.

2. Position 독립적인 코드 옵션 -fPIC 를 사용하여 각 소스 파일을 개체 파일로 컴파일합니다.

   $ gcc ... -c -fPIC some_file.c ...

   오브젝트 파일의 이름은 원본 소스 코드 파일과 동일하지만 해당 확장자는 .o 입니다.

3. 오브젝트 파일에서 공유 라이브러리를 연결합니다.

   $ gcc -shared -o libfoo.so.x.y -Wl,-soname,libfoo.so.x some_file.o ...

   사용된 주 버전 번호는 X 및 부 버전 번호 Y입니다.

4. libfoo.so.x.y 파일을 시스템의 동적 링커가 찾을 수 있는 적절한 위치에 복사합니다. Red Hat Enterprise Linux에서 라이브러리 디렉터리는 /usr/lib64 입니다.

   # cp libfoo.so.x.y /usr/lib64

   이 디렉터리의 파일을 조작하려면 루트 권한이 필요합니다.

5. soname 메커니즘에 대한 심볼릭 링크를 생성합니다.

   # ln -s libfoo.so.x.y libfoo.so.x
   # ln -s libfoo.so.x libfoo.so

절차

1. GCC를 사용하여 중간 개체 파일을 만듭니다.

   $ gcc -c source_file.c ...

   필요한 경우 소스 파일을 더 추가합니다. 결과 오브젝트 파일은 파일 이름을 공유하지만 .o 파일 이름 확장자를 사용합니다.

2. binutils 패키지의 ar 툴을 사용하여 오브젝트 파일을 정적 라이브러리(아카이브)로 전환합니다.

   $ ar rcs libfoo.a source_file.o ...

   libfoo.a 파일이 생성됩니다.

3. nm 명령을 사용하여 결과 아카이브를 검사합니다.

   $ nm libfoo.a

4. 정적 라이브러리 파일을 적절한 디렉터리에 복사합니다.

5. 라이브러리를 연결할 때 GCC는 라이브러리가 정적 연결을 위한 아카이브인 .a 파일 이름 확장자에서 자동으로 인식됩니다.

   $ gcc ... -lfoo ...

절차

1. hellomake 디렉터리를 생성하고 이 디렉터리로 변경합니다.

   $ mkdir hellomake
   $ cd hellomake

2. 다음 콘텐츠를 사용하여 hello.c 파일을 생성합니다.

   #include <stdio.h>
   
   int main(int argc, char *argv[]) {
     printf("Hello, World!\n");
     return 0;
   }

3. 다음 콘텐츠를 사용하여 Makefile 파일을 생성합니다.

   CC=gcc
   CFLAGS=-c -Wall
   SOURCE=hello.c
   OBJ=$(SOURCE:.c=.o)
   EXE=hello
   
   all: $(SOURCE) $(EXE)
   
   $(EXE): $(OBJ)
           $(CC) $(OBJ) -o $@
   
   %.o: %.c
           $(CC) $(CFLAGS) $< -o $@
   
   clean:
           rm -rf $(OBJ) $(EXE)

   중요

   Makefile 레시피 행은 탭 문자로 시작해야 합니다! 설명서에서 위의 텍스트를 복사하는 경우 cut-and-paste 프로세스는 탭 대신 공백을 붙여넣을 수 있습니다. 이 경우 문제를 수동으로 수정합니다.

4. make: 실행

   $ make
   gcc -c -Wall hello.c -o hello.o
   gcc hello.o -o hello

   그러면 실행 가능한 파일 hello 가 생성됩니다.

5. 실행 파일 hello:

   $ ./hello
   Hello, World!

6. Makefile target clean 을 실행하여 생성된 파일을 제거합니다.

   $ make clean
   rm -rf hello.o hello

절차

1. 디버그하려는 애플리케이션 또는 라이브러리에 연결된 GDB를 시작합니다. GDB는 누락된 디버깅 정보를 자동으로 인식하고 실행할 명령을 제안합니다.

   $ gdb -q /bin/ls
   Reading symbols from /bin/ls...Reading symbols from .gnu_debugdata for /usr/bin/ls...(no debugging symbols found)...done.
   (no debugging symbols found)...done.
   Missing separate debuginfos, use: dnf debuginfo-install coreutils-8.30-6.el8.x86_64
   (gdb)

2. exit GDB: q 를 입력하고 Enter 를 사용하여 확인합니다.

   (gdb) q

3. GDB에서 제안하는 명령을 실행하여 required debuginfo 패키지를 설치합니다.

   # dnf debuginfo-install coreutils-8.30-6.el8.x86_64

   dnf 패키지 관리 도구는 변경 사항에 대한 요약을 제공하고 확인을 요청한 후 필요한 모든 파일을 확인, 다운로드 및 설치합니다.

4. case GDB는 debuginfo 패키지를 제안할 수 없으며 애플리케이션 또는 라이브러리에 대한 debuginfo 패키지 가져오기에 설명된 절차를 수동으로 수행합니다.

절차

1. 애플리케이션 또는 라이브러리의 실행 파일을 찾습니다.

   1. 애플리케이션 파일을 찾으려면 which 명령을 사용합니다.

      $ which less
      /usr/bin/less

   2. locate 명령을 사용하여 라이브러리 파일을 찾습니다.

      $ locate libz | grep so
      /usr/lib64/libz.so.1
      /usr/lib64/libz.so.1.2.11

      원래의 디버깅에 오류 메시지를 디버깅하는 이유는 오류 메시지에 언급된 파일과 라이브러리의 추가 번호가 같은 결과를 선택하십시오. 확실하지 않은 경우 나머지 절차에 따라 라이브러리 파일 이름에 추가 번호가 포함되지 않은 결과를 표시하십시오.

      참고

      locate 명령은 mlocate 패키지에서 제공합니다. 설치하고 사용을 활성화하려면 다음을 수행합니다.

      # dnf install mlocate
      # updatedb

2. 파일을 제공한 패키지의 이름 및 버전을 검색합니다.

   $ rpm -qf /usr/lib64/libz.so.1.2.7
   zlib-1.2.11-10.el8.x86_64

   출력은 이름에 설치된 패키지에 대한 세부 정보를 제공합니다 :epoch-version.release.아키텍처 형식입니다.

   중요

   이 단계에서 결과가 생성되지 않으면 바이너리 파일이 제공된 패키지를 결정할 수 없습니다. 다음과 같은 몇 가지 사례가 있습니다.

   • 파일은 현재 구성에서 패키지 관리 툴로 알 수 없는 패키지에서 설치됩니다.
   • 파일은 로컬에서 다운로드되고 수동으로 설치된 패키지에서 설치됩니다. 이러한 경우 적합한 debuginfo 패키지를 자동으로 결정하는 것은 불가능합니다.
   • 패키지 관리 툴이 잘못 구성되어 있습니다.
   • 파일은 어떤 패키지에서도 설치되지 않습니다. 이러한 경우 각 debuginfo 패키지가 존재하지 않습니다.

   추가 단계는 이 문제를 해결하기 때문에 이 상황을 해결하거나 이 절차를 중단해야 합니다. 정확한 문제 해결 단계를 설명하는 것은 이 절차의 범위를 벗어납니다.

3. debuginfo -install 유틸리티를 사용하여debuginfo 패키지를 설치합니다. 명령에서 이전 단계에서 결정한 패키지 이름과 기타 세부 정보를 사용합니다.

   # debuginfo-install zlib-1.2.11-10.el8.x86_64

1. ps 명령을 사용하여 PID(프로세스ID)를 찾습니다.

   $ ps -C program -o pid h
    pid

   program 을 파일 이름 또는 프로그램의 경로로 바꿉니다.

2. 이 프로세스에 GDB를 연결합니다.

   $ gdb -p pid

   ps 출력의 실제 프로세스 ID 번호로 pid 를 바꿉니다.

1. 쉘 GDB 명령을 사용하여 ps 명령을 실행하고 프로그램의 프로세스 ID(pid)를 찾습니다.

   (gdb) shell ps -C program -o pid h
    pid

   program 을 파일 이름 또는 프로그램의 경로로 바꿉니다.

2. attach 명령을 사용하여 GDB를 프로그램에 연결합니다.

   (gdb) attach pid

   ps 출력 의 실제 프로세스 ID 번호로 바꿉니다.

절차

1. 모니터링할 시스템 호출을 식별합니다.

2. strace 를 시작하고 프로그램에 연결합니다.

   • 모니터링할 프로그램이 실행되고 있지 않으면 strace 를 시작하고 프로그램을 지정합니다:

     $ strace -fvttTyy -s 256 -e trace=call program

   • 프로그램이 이미 실행 중인 경우 해당 프로세스 ID(pid)를 찾아 strace 를 연결합니다.

     $ ps -C program
     (...)
     $ strace -fvttTyy -s 256 -e trace=call -ppid

   • 호출 을 표시할 시스템 호출로 바꿉니다. -e trace=call 옵션을 여러 번 사용할 수 있습니다. 제외되는 경우 strace 는 모든 시스템 호출 유형을 표시합니다. 자세한 내용은 strace(1) 매뉴얼 페이지를 참조하십시오.
   • 분기된 프로세스 또는 스레드를 추적하지 않으려면 -f 옵션을 종료합니다.

3. strace 툴은 애플리케이션에서 수행한 시스템 호출과 세부 정보를 표시합니다.

   대부분의 경우 시스템 호출에 대한 필터가 설정되지 않은 경우 애플리케이션 및 해당 라이브러리는 많은 호출을 만들고 strace 출력을 즉시 표시합니다.

4. strace 툴은 프로그램이 종료되면 종료됩니다.

   추적 프로그램이 종료되기 전에 모니터링을 종료하려면 Ctrl+C 를 누릅니다.

   • strace 가 프로그램을 시작하면 strace 와 함께 프로그램이 종료됩니다.
   • strace 를 이미 실행 중인 프로그램에 연결하면 strace 와 함께 프로그램이 종료됩니다.

5. 애플리케이션에서 수행한 시스템 호출 목록을 분석합니다.

   • 리소스 액세스 또는 가용성 관련 문제는 반환 오류를 호출할 때 로그에 있습니다.
   • 시스템 호출 및 호출 시퀀스 패턴에 전달되는 값은 애플리케이션 동작의 원인에 대한 통찰력을 제공합니다.
   • 애플리케이션이 충돌하면 중요한 정보가 로그 끝에 있을 수 있습니다.
   • 출력에는 불필요한 정보가 많이 포함되어 있습니다. 그러나 관심 있는 시스템 호출에 대한 보다 정확한 필터를 구성하고 절차를 반복할 수 있습니다.

절차

1. 가능한 경우 관심 있는 라이브러리 및 기능을 식별합니다.

2. ltrace 를 시작하고 프로그램에 연결합니다.

   • 모니터링할 프로그램이 실행되지 않는 경우 ltrace 를 시작하고 프로그램을 지정합니다:

     $ ltrace -f -l library -e function program

   • 프로그램이 이미 실행중인 경우 해당 프로세스 ID (pid)를 찾아 ltrace 를 연결합니다.

     $ ps -C program
     (...)
     $ ltrace -f -l library -e function program -ppid

   • 출력을 필터링하려면 -e, -f 및 -l 옵션을 사용합니다.

     • 함수로 표시할 함수 이름을 제공합니다 . e 기능 옵션은 여러 번 사용할 수 있습니다. 제외되면 ltrace 는 모든 함수에 대한 호출을 표시합니다.
     • 함수를 지정하는 대신 -l 라이브러리 옵션을 사용하여 전체 라이브러리를 지정할 수 있습니다. 이 옵션은 -e 기능 옵션과 유사하게 작동합니다.
     • 분기된 프로세스 또는 스레드를 추적하지 않으려면 -f 옵션을 종료합니다.

     자세한 내용은 ltrace(1)_ 매뉴얼 페이지를 참조하십시오.

3. ltrace 는 애플리케이션에서 수행한 라이브러리 호출을 표시합니다.

   대부분의 경우 애플리케이션은 필터가 설정되지 않은 경우 많은 수의 호출과 ltrace 출력이 즉시 표시됩니다.

4. ltrace 는 프로그램이 종료되면 종료됩니다.

   추적 프로그램이 종료되기 전에 모니터링을 종료하려면 ctrl+C 를 누릅니다.

   • ltrace 가 프로그램을 시작하면 프로그램은 ltrace 와 함께 종료됩니다.
   • ltrace 를 이미 실행 중인 프로그램에 연결한 경우 프로그램은 ltrace 와 함께 종료됩니다.

5. 애플리케이션에서 수행한 라이브러리 호출 목록을 분석합니다.

   • 애플리케이션이 충돌하면 중요한 정보가 로그 끝에 있을 수 있습니다.
   • 출력에는 불필요한 정보가 많이 포함되어 있습니다. 그러나 더 정확한 필터를 생성하고 절차를 반복할 수 있습니다.

절차

1. 모니터링할 프로세스의PID(프로세스 ID)를 찾습니다.

   $ ps -aux

2. strace.stp 스크립트를 사용하여 SystemTap을 실행합니다.

   # stap /usr/share/systemtap/examples/process/strace.stp -x pid

   pid 값은 프로세스 ID입니다.

   스크립트가 커널 모듈로 컴파일된 다음 로드됩니다. 이렇게 하면 명령을 입력하고 출력을 가져오는 사이에 약간의 지연이 발생합니다.

3. 프로세스에서 시스템 호출을 수행하면 호출 이름과 해당 매개 변수가 터미널에 출력됩니다.
4. 프로세스가 종료되면 스크립트가 종료되거나 Ctrl+C 를 누르면 종료됩니다.

절차

1. catchpoint를 설정합니다.

   (gdb) catch syscall syscall-name

   명령 catch syscall 은 프로그램이 시스템 호출을 수행할 때 실행을 중지하는 특수한 유형의 중단점을 설정합니다.

   syscall-name 옵션은 호출 이름을 지정합니다. 다양한 시스템 호출에 대해 여러 catchpoints를 지정할 수 있습니다. syscall-name 옵션을 벗어나면 GDB가 모든 시스템 호출에서 중지됩니다.

2. 프로그램 실행을 시작합니다.

   • 프로그램이 실행을 시작하지 않은 경우 시작합니다.

     (gdb) r

   • 프로그램 실행이 중지된 경우 다시 시작합니다.

     (gdb) c

3. GDB는 프로그램이 지정된 시스템 호출을 수행한 후 실행을 중지합니다.

절차

1. catchpoint를 설정합니다.

   (gdb) catch signal signal-type

   명령 catch 신호는 프로그램에서 신호를 수신할 때 실행을 중지하는 특별한 유형의 중단점을 설정합니다. signal-type 옵션은 신호 유형을 지정합니다. 특수 값 'all' 을 사용하여 모든 신호를 포착합니다.

2. 프로그램이 실행되도록 합니다.

   • 프로그램이 실행을 시작하지 않은 경우 시작합니다.

     (gdb) r

   • 프로그램 실행이 중지된 경우 다시 시작합니다.

     (gdb) c

3. GDB는 프로그램이 지정된 신호를 받은 후 실행을 중지합니다.

절차

1. 코어 덤프를 활성화하려면 /etc/systemd/system.conf 파일에 다음 행이 포함되어 있는지 확인하십시오.

   DumpCore=yes
   DefaultLimitCORE=infinity

   이러한 설정이 이전에 있는지 및 이전 값이 무엇인지에 대한 주석을 추가할 수도 있습니다. 필요한 경우 나중에 이러한 변경 사항을 되돌릴 수 있습니다. 주석은 # 문자로 시작하는 행입니다.

   파일을 변경하려면 관리자 수준 액세스 권한이 필요합니다.

2. 새 구성을 적용합니다.

   # systemctl daemon-reexec

3. 코어 덤프 크기의 제한을 제거합니다.

   # ulimit -c unlimited

   이 변경을 취소하려면 무제한 이 아니라 값이 0 인 명령을 실행합니다.

4. 시스템 정보 수집을 위한 sosreport 유틸리티를 제공하는 sos 패키지를 설치합니다.

   # dnf install sos

5. 애플리케이션이 충돌하면 systemd-coredump 에 의해 코어 덤프가 생성되고 처리됩니다.

6. 시스템에 대한 추가 정보를 제공하는 SOS 보고서를 생성합니다.

   # sosreport

   이렇게 하면 구성 파일 복사본과 같은 시스템에 대한 정보가 포함된 .tar 아카이브가 생성됩니다.

7. 코어 덤프를 찾아서 내보냅니다.

   $ coredumpctl list executable-name
   $ coredumpctl dump executable-name > /path/to/file-for-export

   애플리케이션이 여러 번 충돌하면 첫 번째 명령의 출력에 더 캡처된 코어 덤프가 나열됩니다. 이 경우 두 번째 명령의 구문을 구문을 사용하여 다른 정보를 사용하여 보다 정확한 쿼리를 만듭니다. 자세한 내용은 coredumpctl(1) 매뉴얼 페이지를 참조하십시오.

8. 코어 덤프와 SOS 보고서를 디버깅이 수행되는 컴퓨터로 전송합니다. 알려진 경우 실행 파일을 전송합니다.

   중요

   실행 파일을 알 수 없는 경우 코어 파일의 후속 분석이 해당 파일을 식별합니다.

9. 선택 사항: 코어 덤프 및 SOS 보고서를 전송 후 제거하여 디스크 공간을 확보합니다.

절차

1. 충돌이 발생한 실행 파일을 식별하려면 코어 덤프 파일을 사용하여 eu-unstrip 명령을 실행합니다.

   $ eu-unstrip -n --core=./core.9814
   0x400000+0x207000 2818b2009547f780a5639c904cded443e564973e@0x400284 /usr/bin/sleep /usr/lib/debug/bin/sleep.debug [exe]
   0x7fff26fff000+0x1000 1e2a683b7d877576970e4275d41a6aaec280795e@0x7fff26fff340 . - linux-vdso.so.1
   0x35e7e00000+0x3b6000 374add1ead31ccb449779bc7ee7877de3377e5ad@0x35e7e00280 /usr/lib64/libc-2.14.90.so /usr/lib/debug/lib64/libc-2.14.90.so.debug libc.so.6
   0x35e7a00000+0x224000 3ed9e61c2b7e707ce244816335776afa2ad0307d@0x35e7a001d8 /usr/lib64/ld-2.14.90.so /usr/lib/debug/lib64/ld-2.14.90.so.debug ld-linux-x86-64.so.2

   출력에는 공백으로 구분된 행의 각 모듈에 대한 세부 정보가 포함되어 있습니다. 정보는 다음 순서로 나열됩니다.

   1. 모듈이 매핑된 메모리 주소
   2. 모듈의 build-id 및 검색된 메모리의 위치
   3. 모듈의 실행 파일 이름, 알 수 없는 경우 또는 로 표시됨 또는 모듈이 파일에서 로드되지 않은 경우
   4. 사용 가능한 경우 파일 이름으로 표시되는 디버깅 정보의 소스입니다 . 실행 파일 자체에 포함된 경우 또는 전혀 표시되지 않는 경우 입니다.
   5. 기본 모듈의 공유 라이브러리 이름(soname) 또는 [exe]

   이 예에서 중요한 세부 사항은 텍스트 [exe] 를 포함하는 행의 파일 이름 /usr/bin/sleep 및 build-id 2818b2009547f780a56394cded443e564973e 입니다. 이 정보를 사용하여 코어 덤프를 분석하는 데 필요한 실행 파일을 식별할 수 있습니다.

2. 충돌한 실행 파일을 가져옵니다.

   • 가능한 경우 충돌이 발생한 시스템에서 복사합니다. 코어 파일에서 추출한 파일 이름을 사용합니다.

   • 시스템에서 동일한 실행 파일을 사용할 수도 있습니다. Red Hat Enterprise Linux를 기반으로 빌드된 각 실행 파일에는 고유한 build-id 값이 포함된 참고 사항이 포함되어 있습니다. 로컬에서 사용 가능한 관련 실행 파일의 build-id를 확인합니다.

     $ eu-readelf -n executable_file

     이 정보를 사용하여 원격 시스템의 실행 파일과 로컬 사본을 일치시킵니다. 코어 덤프에 나열된 로컬 파일 및 build-id의 build-id가 일치해야 합니다.

   • 마지막으로, 애플리케이션이 RPM 패키지에서 설치된 경우 패키지에서 실행 파일을 가져올 수 있습니다. sosreport 출력을 사용하여 필요한 패키지의 정확한 버전을 찾습니다.
3. 실행 파일에서 사용하는 공유 라이브러리를 가져옵니다. 실행 파일에 대해 와 동일한 단계를 사용합니다.
4. 애플리케이션이 패키지로 배포되는 경우 GDB에서 실행 파일을 로드하여 누락된 debuginfo 패키지에 대한 힌트를 표시합니다. 자세한 내용은 3.1.4절. “GDB를 사용하여 애플리케이션 또는 라이브러리의 debuginfo 패키지 가져오기” 의 내용을 참조하십시오.

5. 핵심 파일을 자세히 검사하려면 GDB를 사용하여 실행 파일 및 코어 덤프 파일을 로드합니다.

   $ gdb -e executable_file -c core_file

   누락된 파일 및 디버깅 정보에 대한 추가 메시지는 디버깅 세션에 누락된 항목을 식별하는 데 도움이 됩니다. 필요한 경우 이전 단계로 돌아갑니다.

   애플리케이션의 디버깅 정보를 패키지 대신 파일로 사용할 수 있는 경우 기호-file 명령을 사용하여 GDB에서 이 파일을 로드합니다.

   (gdb) symbol-file program.debug

   program.debug 를 실제 파일 이름으로 교체합니다.

   참고

   코어 덤프에 포함된 모든 실행 파일에 대한 디버깅 정보를 설치할 필요가 없을 수도 있습니다. 이러한 실행 가능한 파일은 애플리케이션 코드에서 사용하는 라이브러리입니다. 이러한 라이브러리는 분석 중인 문제에 직접 기여하지 않을 수 있으며, 디버깅 정보를 포함할 필요가 없습니다.

6. GDB 명령을 사용하여 충돌 시 애플리케이션 상태를 검사합니다. GDB를 사용한 애플리케이션 내부 상태 검사 참조.

   참고

   코어 파일을 분석할 때 GDB는 실행 중인 프로세스에 연결되지 않습니다. 실행을 제어하기 위한 명령에는 아무런 영향이 없습니다.

절차

1. 실행 파일 이름의 알려진 부분에 따라 중단 프로세스의 PID를 찾습니다.

   $ pgrep -a executable-name-fragment

   이 명령은 양식으로 행을 출력합니다.

   PID command-line

   명령줄 값을 사용하여 PID 가 의도한 프로세스에 속하는지 확인합니다.

   예를 들면 다음과 같습니다.

   $ pgrep -a bc
   5459 bc

2. 프로세스에 중단 신호를 보냅니다.

   # kill -ABRT PID

3. core dumpctl에서 코어 를 캡처했는지 확인합니다.

   $ coredumpctl list PID

   예를 들면 다음과 같습니다.

   $ coredumpctl list 5459
   TIME                            PID   UID   GID SIG COREFILE  EXE
   Thu 2019-11-07 15:14:46 CET    5459  1000  1000   6 present   /usr/bin/bc

4. 필요에 따라 핵심 파일을 추가로 검사하거나 사용합니다.

   코어 덤프를 PID 및 기타 값으로 지정할 수 있습니다. 자세한 내용은 coredumpctl(1) 매뉴얼 페이지를 참조하십시오.

   • 핵심 파일의 세부 정보를 보려면 다음을 수행합니다.

     $ coredumpctl info PID

   • GDB 디버거에서 코어 파일을 로드하려면 다음을 수행합니다.

     $ coredumpctl debug PID

     디버깅 정보의 가용성에 따라 GDB에서 실행할 명령을 제안합니다. 예를 들면 다음과 같습니다.

     Missing separate debuginfos, use: dnf debuginfo-install bc-1.07.1-5.el8.x86_64

     이 프로세스에 대한 자세한 내용은 GDB를 사용하여 애플리케이션 또는 라이브러리의 debuginfo 패키지 가져오기 를 참조하십시오.

   • 다른 곳에서 추가 처리를 위해 코어 파일을 내보내려면 다음을 수행합니다.

     $ coredumpctl dump PID > /path/to/file_for_export

     /path/to/file_for_export 를 코어 덤프를 배치하려는 파일로 바꿉니다.

절차

1. 프로세스 ID(pid)를 확인합니다. ps,pgrep 및 top 과 같은 툴 사용 :

   $ ps -C some-program

2. 이 프로세스의 메모리를 덤프합니다.

   $ gcore -o filename pid

   그러면 파일 파일 이름이 생성되고 여기에 프로세스 메모리를 덤프합니다. 메모리가 덤프되는 동안 프로세스 실행이 중지됩니다.

3. 코어 덤프가 완료되면 프로세스가 정상적인 실행을 재개합니다.

4. 시스템에 대한 추가 정보를 제공하는 SOS 보고서를 생성합니다.

   # sosreport

   이렇게 하면 구성 파일 복사본과 같은 시스템에 대한 정보가 포함된 tar 아카이브가 생성됩니다.

5. 프로그램의 실행 파일, 코어 덤프 및 SOS 보고서를 디버깅이 수행되는 컴퓨터로 전송합니다.
6. 선택 사항: 코어 덤프 및 SOS 보고서를 전송 후 제거하여 디스크 공간을 확보합니다.

절차

1. /proc/PID/coredump_filter 파일의 설정을 무시하도록 GDB를 설정합니다.

   (gdb) set use-coredump-filter off

2. 메모리 페이지 플래그 VM_DONTDUMP 를 무시하도록 GDB를 설정합니다.

   (gdb) set dump-excluded-mappings on

3. 메모리를 덤프합니다.

   (gdb) gcore core-file

   core-file 을 메모리를 덤프하려는 파일의 이름으로 바꿉니다.

절차

1. 고객 포털 인증 정보를 사용하여 Red Hat Container Registry 에 액세스합니다.

   $ podman login registry.redhat.io
   Username: username
   Password: ********

2. root로 관련 명령을 실행하여 필요한 컨테이너 이미지를 가져옵니다.

   # podman pull registry.redhat.io/rhel9/gcc-toolset-13-toolchain

   참고

   또한 루트가 아닌 사용자로 컨테이너를 사용하도록 시스템을 설정할 수도 있습니다. 자세한 내용은 루트리스 컨테이너 설정을 참조하십시오.

3. 선택 사항: 로컬 시스템의 모든 컨테이너 이미지를 나열하는 명령을 실행하여 가져오기가 성공했는지 확인합니다.

   # podman images

4. 컨테이너 내에서 bash 쉘을 시작하여 컨테이너를 실행합니다.

   # podman run -it image_name /bin/bash

   i 옵션은 대화식 세션을 생성합니다. 이 옵션 없이 쉘이 열리고 즉시 종료됩니다.

   -t 옵션은 터미널 세션을 엽니다. 이 옵션을 사용하지 않으면 쉘에 아무것도 입력할 수 없습니다.

절차

1. 고객 포털 인증 정보를 사용하여 Red Hat Container Registry에 액세스합니다.

   $ podman login registry.redhat.io
   Username: username
   Password: ********

2. root로 컨테이너 이미지를 가져옵니다.

   # podman pull registry.redhat.io/rhel9/gcc-toolset-13-toolchain

3. root로 대화형 쉘을 사용하여 컨테이너 이미지를 시작합니다.

   # podman run -it registry.redhat.io/rhel9/gcc-toolset-13-toolchain /bin/bash

4. GCC Toolset 툴을 예상대로 실행합니다. 예를 들어 gcc 컴파일러 버전을 확인하려면 다음을 실행합니다.

   bash-4.4$ gcc -v
   ...
   gcc version 13.1.1 20231102 (Red Hat 13.1.1-4) (GCC)

5. 컨테이너에 제공된 모든 패키지를 나열하려면 다음을 실행합니다.

   bash-4.4$ rpm -qa