RHEL 10에서 C 및 C++ 애플리케이션 개발

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

프로세스

1. 터미널에서 소스 코드 파일이 포함된 디렉터리에 대해 엽니다.

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

   $ gcc -c source.c another_source.c

   오브젝트 파일은 원래 소스 코드 파일을 반영하는 파일 이름으로 생성됩니다. source.c 결과는 source.o 입니다.

   참고

   C++ 소스 코드를 사용하면 C++ 표준 라이브러리 종속성을 편리하게 처리하기 위해 gcc 명령을 g++ 로 바꿉니다.

프로세스

1. 오브젝트 코드 파일이 포함된 디렉터리로 변경합니다.

2. run gcc:

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

   executable-file 이라는 실행 파일은 제공된 오브젝트 파일 및 라이브러리에서 생성됩니다. 추가 라이브러리를 연결하려면 오브젝트 파일 목록 뒤에 필요한 옵션을 추가합니다.

   자세한 내용은 GCC에서 라이브러리 사용을 참조하십시오.

   참고

   C++ 소스 코드를 사용하면 C++ 표준 라이브러리 종속성을 편리하게 처리하기 위해 gcc 명령을 g++ 로 바꿉니다.

프로세스

1. hello-c 디렉토리를 생성합니다.

   $ mkdir hello-c

2. 생성된 디렉터리로 변경합니다.

   $ cd hello-c

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

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

4. 코드를 컴파일하고 GCC에 연결합니다.

   $ gcc hello.c -o helloworld

   이렇게 하면 코드를 컴파일하고 개체 파일 hello.o.o를 만들고 개체 파일에서 실행 파일 helloworld 를 연결합니다.

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

   $ ./helloworld

   Hello, World!

프로세스

1. hello-c 디렉토리를 생성합니다.

   $ mkdir hello-c

2. 생성된 디렉터리로 변경합니다.

   $ cd hello-c

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

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

4. GCC를 사용하여 코드를 컴파일합니다.

   $ gcc -c hello.c

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

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

   $ gcc hello.o -o helloworld

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

   $ ./helloworld
   Hello, World!

7. 선택 사항: 상위 디렉터리로 다시 변경합니다.

   $ cd ..

8. 선택 사항: hello-c 디렉터리를 제거합니다.

   $ rm -r hello-c

프로세스

1. hello-cpp 디렉토리를 생성합니다.

   $ mkdir hello-cpp

2. 생성된 디렉터리로 변경합니다.

   $ cd hello-cpp

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

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

4. 코드를 컴파일하고 g++ 로 연결합니다.

   $ g++ hello.cpp -o helloworld

   이렇게 하면 코드를 컴파일하고 개체 파일 hello.o.o를 만들고 개체 파일에서 실행 파일 helloworld 를 연결합니다.

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

   $ ./helloworld

   Hello, World!

6. 선택 사항: 상위 디렉터리로 다시 변경합니다.

   $ cd ..

7. 선택 사항: hello-cpp 디렉터리를 제거합니다.

   $ rm -r hello-cpp

프로세스

1. hello-cpp 디렉토리를 생성합니다.

   $ mkdir hello-cpp

2. 생성된 디렉터리로 변경합니다.

   $ cd hello-cpp

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

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

4. g++ 로 코드를 컴파일합니다.

   $ g++ -c hello.cpp

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

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

   $ g++ hello.o -o helloworld

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

   $ ./helloworld

   Hello, World!

7. 선택 사항: 상위 디렉터리로 다시 변경합니다.

   $ cd ..

8. 선택 사항: hello-cpp 디렉터리를 제거합니다.

   $ rm -r hello-cpp

프로세스

1. 라이브러리 소스가 있는 디렉터리로 변경합니다.

2. 독립적인 코드 옵션 -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

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

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

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

6. 링커 이름에 대한 심볼릭 링크를 생성합니다.

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

프로세스

1. GCC를 사용하여 중간 오브젝트 파일을 생성합니다.

   $ gcc -c source_file.c ...

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

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

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

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

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

   $ nm libfoo.a

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

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

   $ gcc ... -lfoo ...

프로세스

1. hellomake 디렉토리를 생성합니다.

   $ mkdir hellomake

2. 생성된 디렉터리로 변경합니다.

   $ cd hellomake

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

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

4. 다음 콘텐츠를 사용하여 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 프로세스가 탭 대신 공백을 붙여넣을 수 있습니다. 이 경우 문제를 수동으로 수정합니다.

5. 실행 make:

   $ make

   gcc -c -Wall hello.c -o hello.o
   gcc hello.o -o hello

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

6. 실행 파일 hello 를 실행합니다.

   $ ./hello

   Hello, World!

7. 생성된 파일을 제거하려면 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-9.5-6.el10.x86_64
   (gdb)

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

   (gdb) q

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

   # dnf debuginfo-install coreutils-9.5-6.el10.x86_64

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

4. GDB가 debuginfo 패키지를 제안할 수 없는 경우 에 설명된 절차를 따르십시오.

   • 애플리케이션 또는 라이브러리의 debuginfo 패키지를 수동으로 가져옵니다.

프로세스

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

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

      $ 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

      1. 데이터베이스를 업데이트합니다.

         # updatedb

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

   $ rpm -qf /usr/lib64/libz.so.1.3.1.zlib-ng

   zlib-ng-compat-2.2.3-1.el10.x86_64

   출력은 다음과 같이 이름:epoch-버전.릴리스.아키텍처 형식으로 설치된 패키지에 대한 세부 정보를 제공합니다.

   중요

   이 단계에서 결과가 생성되지 않으면 바이너리 파일을 제공한 패키지를 확인할 수 없습니다. 몇 가지 가능한 사례가 있습니다.

   • 파일은 현재 구성의 패키지 관리 도구에서 알 수 없는 패키지에서 설치됩니다.
   • 파일은 로컬로 다운로드되고 수동으로 설치된 패키지에서 설치됩니다. 이 경우 적절한 debuginfo 패키지를 자동으로 확인할 수 없습니다.
   • 패키지 관리 툴이 잘못 구성되어 있습니다.
   • 파일이 어떤 패키지에서도 설치되지 않았습니다. 이러한 경우 해당 debuginfo 패키지가 없습니다.

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

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

   # dnf debuginfo-install zlib-ng-compat-2.2.3-1.el10.x86_64

프로세스

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

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

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

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

     • 프로그램이 이미 실행중인 경우 프로세스 ID (pid)를 찾으십시오.

       $ ps -C program

     • 프로세스에 strace 를 연결합니다.

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

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

2. strace 툴에는 애플리케이션에서 수행한 시스템 호출과 세부 정보가 표시됩니다.

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

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

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

   • strace 가 프로그램을 시작한 경우 프로그램은 strace 와 함께 종료됩니다.
   • 이미 실행중인 프로그램에 strace 를 첨부한 경우 프로그램은 strace 와 함께 종료됩니다.

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

   • 리소스 액세스 또는 가용성에 대한 문제는 호출에서 오류를 반환할 때 로그에 존재합니다.
   • 시스템 호출 및 호출 시퀀스 패턴에 전달된 값은 애플리케이션의 동작 원인에 대한 통찰력을 제공합니다.
   • 애플리케이션이 충돌하면 중요한 정보는 로그 끝에 있을 수 있습니다.

   • 출력에는 많은 불필요한 정보가 포함되어 있습니다. 그러나 관심 있는 시스템 호출에 대한 보다 정확한 필터를 구성하고 절차를 반복할 수 있습니다.

     참고

     출력을 보고 파일에 저장하는 것이 좋습니다. 이 작업을 수행하려면 tee 명령을 사용합니다.

     $ strace ... |& tee your_log_file.log

프로세스

1. 가능한 경우 라이브러리 및 관심 함수를 식별합니다.

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

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

     $ ltrace -f -l library -e function program

   • 프로그램이 이미 실행중인 경우 프로세스 ID (pid)를 찾으십시오.

     $ ps -C program

   • ltrace 를 프로세스에 연결합니다.

     $ ltrace -f -l library -e function -ppid program

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

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

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

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

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

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

   추적된 프로그램이 종료되기 전에 모니터링을 종료하려면 ctrl+C 를 누릅니다. * ltrace 가 프로그램을 시작한 경우 프로그램은 ltrace 와 함께 종료됩니다. * 이미 실행중인 프로그램에 ltrace 를 첨부하면 프로그램이 ltrace 와 함께 종료됩니다.

5. Ctrl+C 를 눌러 ltrace 를 중지합니다.

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

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

프로세스

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

   $ 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 은 프로그램이 시스템 호출을 수행할 때 실행을 중단하는 특수 유형의 Cryostat를 설정합니다.

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

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

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

     (gdb) r

   • 프로그램 실행이 중지되면 다시 시작하십시오.

     (gdb) c

3. GDB는 프로그램이 지정된 시스템 호출을 수행한 후 실행을 중지합니다.
4. 특정 상황에 따라 프로그램 상태 및 사전 실행을 검사하려면 추가 GDB 명령을 사용하십시오.

5. GDB 디버깅 세션을 종료하려면 다음을 수행합니다.

   (gdb) q

프로세스

1. catchpoint를 설정합니다.

   (gdb) catch signal signal-type

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

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

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

     (gdb) r

   • 프로그램 실행이 중지되면 다시 시작하십시오.

     (gdb) c

3. GDB는 프로그램이 지정된 신호를 수신한 후 실행을 중지합니다.
4. 신호를 처리하는 프로그램 코드를 디버깅하거나 수신되는 신호에 대한 지식을 사용하여 실행을 재개합니다.

5. 나중에 GDB 디버깅 세션을 종료하려면 다음을 수행합니다.

   (gdb) q

프로세스

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

8. 코어 덤프를 내보냅니다.

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

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

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

   중요

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

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

프로세스

1. 크래시가 발생한 실행 파일을 확인하려면 core dump 파일을 사용하여 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 2818b2009547f780a5639c904cded443e564973e 564973e입니다. 이 정보를 사용하면 코어 덤프 분석에 필요한 실행 파일을 확인할 수 있습니다.

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

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

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

     $ eu-readelf -n executable_file

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

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

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

   $ gdb -e executable_file -c core_file

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

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

   (gdb) symbol-file program.debug

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

   참고

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

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

   참고

   코어 파일을 분석할 때 GDB는 실행 중인 프로세스에 연결되어 있지 않습니다. 실행을 제어하는 명령은 영향을 미치지 않습니다.

7. 종료 시 애플리케이션 스택만 보려면 eu-stack 유틸리티를 사용하여 코어 파일을 엽니다.

   $ *eu-stack --core __core-file__*

   그러면 애플리케이션 스택 목록이 표시됩니다.

프로세스

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

   $ pgrep -a executable-name-fragment

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

   PID command-line

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

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

   $ pgrep -a bc

   5459 bc

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

   # kill -ABRT PID

3. coredumpctl 에 의해 코어가 캡처되었는지 확인합니다.

   $ 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-23.el10.x86_64

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

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

     $ coredumpctl dump PID > /path/to/file_for_export

   • /path/to/file_for_export 를 코어 덤프를 배치할 파일로 바꿉니다.

     $ coredumpctl dump PID > /path/to/file_for_export

프로세스

1. 프로세스 ID(pid)를 확인합니다. ps,pgrep 와 같은 도구를 사용하십시오.

   $ 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. GCC Toolset 버전 N:에서 사용할 수 있는 패키지를 나열합니다.

   $ dnf list available gcc-toolset-N-\

2. 다음 패키지를 설치하려면 다음을 수행합니다.

   # dnf install package_name

   package_name 을 설치할 패키지 목록으로 바꿉니다. 예를 들어 gcc-toolset-15-annobin-annocheck 및 gcc-toolset-15-binutils-devel 패키지를 설치하려면 다음을 수행합니다.

   # dnf install gcc-toolset-15-annobin-annocheck gcc-toolset-15-binutils-devel

1. 플러그인 디렉터리로 변경합니다.

   $ cd /opt/rh/gcc-toolset-15/root/usr/lib/gcc/architecture-linux-gnu/15/plugin

2. annobin.so에서 gcc- annobin.so 에 심볼릭 링크를 만듭니다.

   $ ln -s annobin.so gcc-annobin.so