1. Los archivos fuente se compilan en archivos objeto.
2. Se enlazan los archivos de objetos y las bibliotecas (incluyendo las fuentes previamente compiladas).

Procedimiento

1. Cambie al directorio que contiene los archivos de código fuente.

2. Ejecute gcc con la opción -c:

   $ gcc -c source.c another_source.c

   Se crean archivos de objetos, cuyos nombres reflejan los archivos de código fuente originales: source.c da como resultado source.o.

   Nota

   Con el código fuente de C, sustituya el comando gcc por g para manejar convenientemente las dependencias de la biblioteca estándar de C.

Procedimiento

1. Cambie al directorio que contiene los archivos de código objeto.

2. Ejecutar gcc:

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

   Se crea un archivo ejecutable llamado executable-file se crea a partir de los archivos de objetos y bibliotecas suministrados.

   Para enlazar bibliotecas adicionales, añada las opciones necesarias después de la lista de archivos de objetos. Para más información, consulte Capítulo 3, Uso de bibliotecas con GCC.

   Nota

   Con el código fuente de C, sustituya el comando gcc por g para manejar convenientemente las dependencias de la biblioteca estándar de C.

Procedimiento

1. Cree un directorio hello-c y cambie a él:

   $ mkdir hello-c
   $ cd hello-c

2. Cree el archivo hello.c con el siguiente contenido:

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

3. Compilar el código con GCC:

   $ gcc -c hola.c

   Se crea el archivo de objetos hello.o.

4. Enlaza un archivo ejecutable helloworld desde el archivo objeto:

   $ gcc hello.o -o helloworld

5. Ejecute el archivo ejecutable resultante:

   $ ./helloworld
   Hello, World!

Procedimiento

1. Cree un directorio hello-cpp y cambie a él:

   $ mkdir hello-cpp
   $ cd hello-cpp

2. Cree el archivo hello.cpp con el siguiente contenido:

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

3. Compila el código con g :

   $ g -c hola.cpp

   Se crea el archivo de objetos hello.o.

4. Enlaza un archivo ejecutable helloworld desde el archivo objeto:

   $ g hello.o -o helloworld

5. Ejecute el archivo ejecutable resultante:

   $ ./helloworld
   Hello, World!

1. Cambie al directorio que contiene su código.

2. Compilar los archivos fuente del programa con las cabeceras de la biblioteca foo:

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

   Sustituya header_path por una ruta a un directorio que contenga los archivos de cabecera de la biblioteca foo.

3. Enlaza el programa con la biblioteca foo:

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

   Sustituya library_path por una ruta a un directorio que contenga el archivo libfoo.a.

4. Para ejecutar el programa más tarde, simplemente:

   $ ./programa

Procedimiento

1. Cambie al directorio con las fuentes de la biblioteca.

2. Compile cada archivo fuente en un archivo objeto con la opción de código independiente de la posición -fPIC:

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

   Los archivos objeto tienen los mismos nombres de archivo que los del código fuente original, pero su extensión es .o.

3. Enlaza la biblioteca compartida desde los archivos de objetos:

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

   El número de versión mayor utilizado es X y el número de versión menor Y.

4. Copie el archivo libfoo.so.x.y en una ubicación apropiada, donde el enlazador dinámico del sistema pueda encontrarlo. En Red Hat Enterprise Linux, el directorio para las bibliotecas es /usr/lib64:

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

   Tenga en cuenta que necesita permisos de root para manipular los archivos de este directorio.

5. Crear la estructura de enlaces simbólicos para el mecanismo de soname:

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

Procedimiento

1. Crear archivos de objetos intermedios con GCC.

   $ gcc -c source_file.c...

   Añada más archivos fuente si es necesario. Los archivos objeto resultantes comparten el nombre del archivo pero utilizan la extensión de nombre de archivo .o.

2. Convierta los ficheros objeto en una biblioteca estática (archivo) utilizando la herramienta ar del paquete binutils.

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

   Se crea el archivo libfoo.a.

3. Utilice el comando nm para inspeccionar el archivo resultante:

   $ nm libfoo.a

4. Copie el archivo de la biblioteca estática en el directorio correspondiente.

5. Al enlazar con la biblioteca, GCC reconocerá automáticamente, a partir de la extensión del nombre del archivo .a, que la biblioteca es un archivo para el enlace estático.

   $ gcc ... -lfoo...

Procedimiento

1. Cree un directorio hellomake y cambie a este directorio:

   $ mkdir hellomake
   $ cd hellomake

2. Cree un archivo hello.c con el siguiente contenido:

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

3. Cree un archivo Makefile con el siguiente contenido:

   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)

   Atención

   Las líneas de la receta del Makefile deben comenzar con el carácter de tabulación Al copiar el texto anterior de la documentación, el proceso de cortar y pegar puede pegar espacios en lugar de tabulaciones. Si esto ocurre, corrija el problema manualmente.

4. Ejecutar make:

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

   Esto crea un archivo ejecutable hello.

5. Ejecute el archivo ejecutable hello:

   $ ./hello
   Hello, World!

6. Ejecute el objetivo de Makefile clean para eliminar los archivos creados:

   $ make clean
   rm -rf hello.o hello

Procedimiento

1. Inicie GDB conectado a la aplicación o biblioteca que desea depurar. GDB reconoce automáticamente la información de depuración que falta y sugiere un comando a ejecutar.

   $ 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. Salir de GDB: escribir q y confirmar con Enter.

   (gdb) q

3. Ejecute el comando sugerido por GDB para instalar los paquetes necesarios de debuginfo:

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

   La herramienta de gestión de paquetes dnf ofrece un resumen de los cambios, pide confirmación y, una vez confirmada, descarga e instala todos los archivos necesarios.

4. En caso de que GDB no pueda sugerir el paquete debuginfo, siga el procedimiento descrito en Sección 7.5, “Obtener manualmente los paquetes debuginfo de una aplicación o biblioteca”.

Procedimiento

1. Encuentra el archivo ejecutable de la aplicación o biblioteca.

   1. Utilice el comando which para encontrar el archivo de la aplicación.

      $ which less
      /usr/bin/less

   2. Utilice el comando locate para encontrar el archivo de la biblioteca.

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

      Si los motivos originales de la depuración incluyen mensajes de error, elija el resultado en el que la biblioteca tiene los mismos números adicionales en su nombre de archivo que los mencionados en los mensajes de error. En caso de duda, intente seguir el resto del procedimiento con el resultado en el que el nombre del archivo de la biblioteca no incluye números adicionales.

      Nota

      El comando locate es proporcionado por el paquete mlocate. Para instalarlo y habilitar su uso:

      # yum install mlocate
      # updatedb

2. Busca el nombre y la versión del paquete que proporcionó el archivo:

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

   La salida proporciona detalles del paquete instalado en el formato name:epoch-version.release.architecture.

   Importante

   Si este paso no produce ningún resultado, no es posible determinar qué paquete proporcionó el archivo binario. Hay varios casos posibles:

   • El archivo se instala desde un paquete que no es conocido por las herramientas de gestión de paquetes en su configuración current.
   • El archivo se instala a partir de un paquete descargado localmente e instalado manualmente. En ese caso es imposible determinar automáticamente un paquete debuginfo adecuado.
   • Sus herramientas de gestión de paquetes están mal configuradas.
   • El archivo no se instala desde ningún paquete. En tal caso, no existe ningún paquete respectivo de debuginfo.

   Dado que los pasos posteriores dependen de éste, debe resolver esta situación o abortar este procedimiento. Describir los pasos exactos de la solución de problemas está fuera del alcance de este procedimiento.

3. Instale los paquetes de debuginfo utilizando la utilidad debuginfo-install. En el comando, utilice el nombre del paquete y otros detalles que determinó durante el paso anterior:

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

1. Encuentre el ID del proceso (pid) con el comando ps:

   $ ps -C program -o pid h
    pid

   Sustituya program por un nombre de archivo o una ruta de acceso al programa.

2. Adjunte el BGF a este proceso:

   $ gdb -p pid

   Sustituya pid por un número de identificación de proceso real de la salida de ps.

1. Utilice el comando GDB shell para ejecutar el comando ps y encontrar el ID del proceso del programa (pid):

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

   Sustituya program por un nombre de archivo o una ruta de acceso al programa.

2. Utilice el comando attach para adjuntar GDB al programa:

   (gdb) adjuntar pid

   Sustituya pid por un número de identificación de proceso real de la salida de ps.

Procedimiento

1. Identifique las llamadas del sistema a supervisar.

2. Inicie strace y adjúntelo al programa.

   • Si el programa que desea supervisar no se está ejecutando, inicie strace y especifique el program:

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

   • Si el programa ya se está ejecutando, busque su id de proceso (pid) y adjunte strace a él:

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

   • Sustituya call por las llamadas al sistema que deben mostrarse. Puede utilizar la opción -e trace=call varias veces. Si se omite, strace mostrará todos los tipos de llamadas del sistema. Consulte la página del manual strace(1) para obtener más información.
   • Si no desea rastrear ningún proceso o hilo bifurcado, omita la opción -f.

3. La herramienta strace muestra las llamadas al sistema realizadas por la aplicación y sus detalles.

   En la mayoría de los casos, una aplicación y sus bibliotecas realizan un gran número de llamadas y la salida strace aparece inmediatamente, si no se establece un filtro para las llamadas al sistema.

4. La herramienta strace sale cuando el programa se cierra.

   Para terminar la monitorización antes de que el programa trazado salga, pulse Ctrl C.

   • Si strace inició el programa, el programa termina junto con strace.
   • Si se adjunta strace a un programa que ya se está ejecutando, el programa termina junto con strace.

5. Analizar la lista de llamadas al sistema realizadas por la aplicación.

   • Los problemas de acceso o disponibilidad de recursos aparecen en el registro como llamadas que devuelven errores.
   • Los valores pasados a las llamadas del sistema y los patrones de las secuencias de llamadas permiten conocer las causas del comportamiento de la aplicación.
   • Si la aplicación se bloquea, la información importante probablemente esté al final del registro.
   • La salida contiene mucha información innecesaria. Sin embargo, puede construir un filtro más preciso para las llamadas al sistema que le interesen y repetir el procedimiento.

Procedimiento

1. Identifique las bibliotecas y funciones de interés, si es posible.

2. Inicie ltrace y adjúntelo al programa.

   • Si el programa que desea supervisar no se está ejecutando, inicie ltrace y especifique program:

     $ ltrace -f -l library -e function program

   • Si el programa ya se está ejecutando, busque su id de proceso (pid) y adjunte ltrace a él:

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

   • Utilice las opciones -e, -f y -l para filtrar la salida:

     • Suministre los nombres de las funciones que se mostrarán como function. La opción -e function puede utilizarse varias veces. Si se omite, ltrace muestra las llamadas a todas las funciones.
     • En lugar de especificar funciones, puede especificar bibliotecas completas con la opción -l library opción. Esta opción se comporta de forma similar a la opción -e function opción.
     • Si no desea rastrear ningún proceso o hilo bifurcado, omita la opción -f.

     Consulte la página del manual ltrace(1)_ para más información.

3. ltrace muestra las llamadas a la biblioteca realizadas por la aplicación.

   En la mayoría de los casos, una aplicación realiza un gran número de llamadas y la salida ltrace se muestra inmediatamente, si no se establece ningún filtro.

4. ltrace sale cuando el programa se cierra.

   Para terminar la monitorización antes de que el programa rastreado salga, pulse ctrl C.

   • Si ltrace inició el programa, el programa termina junto con ltrace.
   • Si se adjunta ltrace a un programa que ya se está ejecutando, el programa termina junto con ltrace.

5. Analizar la lista de llamadas a la biblioteca realizadas por la aplicación.

   • Si la aplicación se bloquea, la información importante probablemente esté al final del registro.
   • El resultado contiene mucha información innecesaria. Sin embargo, puede construir un filtro más preciso y repetir el procedimiento.

Procedimiento

1. Busque el ID del proceso (pid) del proceso que desea supervisar:

   $ ps -aux

2. Ejecute SystemTap con el script strace.stp:

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

   El valor de pid es el identificador del proceso.

   El script se compila en un módulo del kernel, que luego se carga. Esto introduce un ligero retraso entre la introducción del comando y la obtención de la salida.

3. Cuando el proceso realiza una llamada al sistema, el nombre de la llamada y sus parámetros se imprimen en el terminal.
4. El script sale cuando el proceso termina, o cuando se presiona Ctrl C.

Procedimiento

1. Establece el punto de captura:

   (gdb) catch syscall syscall-name

   El comando catch syscall establece un tipo especial de punto de interrupción que detiene la ejecución cuando el programa realiza una llamada al sistema.

   La opción syscall-name especifica el nombre de la llamada. Puede especificar varios puntos de captura para varias llamadas al sistema. Si se omite la opción syscall-name hace que GDB se detenga en cualquier llamada al sistema.

2. Iniciar la ejecución del programa.

   • Si el programa no ha iniciado su ejecución, inícielo:

     (gdb) r

   • Si la ejecución del programa se detiene, reanúdela:

     (gdb) c

3. GDB detiene la ejecución después de que el programa realice cualquier llamada al sistema especificada.

Procedimiento

1. Establece el punto de captura:

   (gdb) atrapar señal signal-type

   El comando catch signal establece un tipo especial de punto de interrupción que detiene la ejecución cuando el programa recibe una señal. La opción signal-type especifica el tipo de señal. Utilice el valor especial 'all' para capturar todas las señales.

2. Deja que el programa se ejecute.

   • Si el programa no ha iniciado su ejecución, inícielo:

     (gdb) r

   • Si la ejecución del programa se detiene, reanúdela:

     (gdb) c

3. GDB detiene la ejecución después de que el programa reciba cualquier señal especificada.

Procedimiento

1. Para habilitar los volcados de núcleo, asegúrese de que el archivo /etc/systemd/system.conf contiene las siguientes líneas:

   DumpCore=yes
   DefaultLimitCORE=infinity

   También puede añadir comentarios que describan si estos ajustes estaban presentes anteriormente, y cuáles eran los valores anteriores. Esto le permitirá revertir estos cambios más tarde, si es necesario. Los comentarios son líneas que comienzan con el carácter #.

   La modificación del archivo requiere un acceso de nivel de administrador.

2. Aplique la nueva configuración:

   # systemctl daemon-reexec

3. Eliminar los límites de los tamaños de volcado del núcleo:

   # ulimit -c unlimited

   Para invertir este cambio, ejecute el comando con el valor 0 en lugar de unlimited.

4. Instale el paquete sos que proporciona la utilidad sosreport para recopilar información del sistema:

   # yum install sos

5. Cuando una aplicación se bloquea, se genera un volcado del núcleo que es gestionado por systemd-coredump.

6. Crear un informe SOS para proporcionar información adicional sobre el sistema:

   # sosreport

   Esto crea un archivo .tar que contiene información sobre su sistema, como copias de los archivos de configuración.

7. Localice y exporte el volcado del núcleo:

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

   Si la aplicación se estrelló varias veces, la salida del primer comando enumera más volcados de núcleo capturados. En ese caso, construya para el segundo comando una consulta más precisa utilizando la otra información. Consulte la página del manual coredumpctl(1) para más detalles.

8. Transfiera el volcado del núcleo y el informe SOS al ordenador donde se realizará la depuración. Transfiera también el archivo ejecutable, si lo conoce.

   Importante

   Cuando no se conoce el archivo ejecutable, el análisis posterior del archivo central lo identifica.

9. Opcional: Elimine el volcado del núcleo y el informe SOS después de transferirlos, para liberar espacio en el disco.

Procedimiento

1. Para identificar el archivo ejecutable en el que se produjo el fallo, ejecute el comando eu-unstrip con el archivo de volcado del núcleo:

   $ 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

   La salida contiene detalles para cada módulo en una línea, separados por espacios. La información aparece en este orden:

   1. La dirección de memoria a la que se asignó el módulo
   2. El build-id del módulo y en qué lugar de la memoria se encuentra
   3. El nombre del archivo ejecutable del módulo, mostrado como - cuando es desconocido, o como . cuando el módulo no ha sido cargado desde un archivo
   4. La fuente de información de depuración, mostrada como un nombre de archivo cuando está disponible, como . cuando está contenida en el propio archivo ejecutable, o como - cuando no está presente en absoluto
   5. El nombre de la biblioteca compartida (soname) o [exe] para el módulo principal

   En este ejemplo, los detalles importantes son el nombre del archivo /usr/bin/sleep y el build-id 2818b2009547f780a5639c904cded443e564973e en la línea que contiene el texto [exe]. Con esta información, puedes identificar el archivo ejecutable necesario para analizar el volcado del núcleo.

2. Obtenga el archivo ejecutable que se estrelló.

   • Si es posible, cópielo del sistema en el que se produjo el fallo. Utilice el nombre del archivo extraído del archivo del núcleo.

   • También puede utilizar un archivo ejecutable idéntico en su sistema. Cada archivo ejecutable construido en Red Hat Enterprise Linux contiene una nota con un valor único de build-id. Determine el build-id de los archivos ejecutables relevantes disponibles localmente:

     $ eu-readelf -n executable_file

     Utilice esta información para hacer coincidir el archivo ejecutable del sistema remoto con su copia local. El build-id del archivo local y el build-id que aparece en el volcado del núcleo deben coincidir.

   • Por último, si la aplicación se instala desde un paquete RPM, puede obtener el archivo ejecutable del paquete. Utilice la salida de sosreport para encontrar la versión exacta del paquete requerido.
3. Obtenga las bibliotecas compartidas utilizadas por el archivo ejecutable. Utilice los mismos pasos que para el archivo ejecutable.
4. Si la aplicación se distribuye como un paquete, cargue el archivo ejecutable en GDB, para mostrar pistas sobre los paquetes de depuración que faltan. Para más detalles, consulte Sección 7.4, “Obtención de paquetes debuginfo para una aplicación o librería usando GDB”.

5. Para examinar el archivo del núcleo en detalle, cargue el archivo ejecutable y el archivo de volcado del núcleo con GDB:

   $ gdb -e executable_file -c core_file

   Otros mensajes sobre los archivos que faltan y la información de depuración le ayudan a identificar lo que falta para la sesión de depuración. Vuelva al paso anterior si es necesario.

   Si la información de depuración de la aplicación está disponible como un archivo en lugar de como un paquete, cargue este archivo en GDB con el comando symbol-file:

   (gdb) archivo-símbolo program.debug

   Sustituya program.debug por el nombre real del archivo.

   Nota

   Puede que no sea necesario instalar la información de depuración para todos los archivos ejecutables contenidos en el volcado del núcleo. La mayoría de estos archivos ejecutables son bibliotecas utilizadas por el código de la aplicación. Es posible que estas bibliotecas no contribuyan directamente al problema que se está analizando, y no es necesario incluir información de depuración para ellas.

6. Utilice los comandos GDB para inspeccionar el estado de la aplicación en el momento en que se estrelló. Ver Capítulo 8, Inspección del estado interno de la aplicación con GDB.

   Nota

   Cuando se analiza un archivo de núcleo, GDB no se adjunta a un proceso en ejecución. Los comandos para controlar la ejecución no tienen efecto.

Procedimiento

1. Encuentra el PID del proceso colgado, basado en una parte conocida del nombre del archivo ejecutable:

   $ pgrep -a executable-name-fragment

   Este comando mostrará una línea de la forma

   PID command-line

   Utilice el valor de command-line para verificar que el PID pertenece al proceso previsto.

   Por ejemplo:

   $ pgrep -a bc
   5459 bc

2. Envía una señal de aborto al proceso:

   # kill -ABRT PID

3. Verifique que el núcleo ha sido capturado por coredumpctl:

   $ coredumpctl list PID

   Por ejemplo:

   $ 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. Examine más a fondo o utilice el archivo del núcleo según sea necesario.

   Puede especificar el volcado del núcleo por PID y otros valores. Consulte la página del manual coredumpctl(1) para obtener más detalles.

   • Para mostrar los detalles del archivo del núcleo:

     $ coredumpctl info PID

   • Para cargar el archivo del núcleo en el depurador GDB:

     $ coredumpctl debug PID

     Dependiendo de la disponibilidad de la información de depuración, GDB sugerirá comandos a ejecutar, como por ejemplo

     Faltan los debuginfos por separado, utilice: dnf debuginfo-install bc-1.07.1-5.el8.x86_64

     Para más detalles sobre este proceso, consulte Sección 7.4, “Obtención de paquetes debuginfo para una aplicación o librería usando GDB”.

   • Para exportar el archivo de núcleo para su posterior procesamiento en otro lugar:

     $ coredumpctl dump PID > /path/to/file_for_export

     Sustituya /path/to/file_for_export por el archivo en el que desea colocar el volcado del núcleo.

Procedimiento

1. Averigüe la identificación del proceso (pid). Utilice herramientas como ps, pgrep, y top:

   $ ps -C some-program

2. Vuelca la memoria de este proceso:

   $ gcore -o filename pid

   Esto crea un archivo filename y vuelca en él la memoria del proceso. Mientras se vuelca la memoria, se detiene la ejecución del proceso.

3. Una vez finalizado el volcado del núcleo, el proceso reanuda su ejecución normal.

4. Crear un informe SOS para proporcionar información adicional sobre el sistema:

   # sosreport

   Esto crea un archivo tar que contiene información sobre su sistema, como copias de los archivos de configuración.

5. Transfiera el archivo ejecutable del programa, el volcado del núcleo y el informe SOS al ordenador donde se realizará la depuración.
6. Opcional: Elimine el volcado del núcleo y el informe SOS después de transferirlos, para liberar espacio en el disco.

Procedimiento

1. Configurar el GDB para que ignore la configuración del archivo /proc/PID/coredump_filter:

   (gdb) set use-coredump-filter off

2. Configurar GDB para que ignore la bandera de la página de memoria VM_DONTDUMP:

   (gdb) set dump-excluded-mappings on

3. Vuelca la memoria:

   (gdb) gcore core-file

   Sustituye core-file por el nombre del archivo donde quieres volcar la memoria.

Procedimiento

1. Lista de los paquetes disponibles en la versión de GCC Toolset N:

   $ yum list available gcc-toolset-N-\N-

2. Para instalar cualquiera de estos paquetes:

   # yum install package_name

   Sustituya package_name por una lista separada por espacios de los paquetes a instalar. Por ejemplo, para instalar los paquetes gcc-toolset-9-gdb-gdbserver y gcc-toolset-9-gdb-doc:

   # yum install gcc-toolset-9-gdb-gdbserver gcc-toolset-9-gdb-doc

Procedimiento

1. Acceda al Red Hat Container Registry utilizando sus credenciales del Portal del Cliente:

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

2. Extraiga una imagen de contenedor que necesite ejecutando un comando relevante como root:

   # podman pull registry.redhat.io/rhel8/gcc-toolset-10-toolchain

   # podman pull registry.redhat.io/rhel8/gcc-toolset-10-perftools

   Nota

   En RHEL 8.1 y versiones posteriores, puede configurar su sistema para trabajar con contenedores como usuario no root. Para más detalles, consulte Ejecutar contenedores como root o sin root.

3. Opcional: Compruebe que la extracción se ha realizado con éxito ejecutando un comando que liste todas las imágenes de contenedores en su sistema local:

   # imágenes de podman

4. Ejecutar un contenedor lanzando un shell bash dentro de un contenedor:

   # podman run -it image_name /bin/bash

   La opción -i crea una sesión interactiva; sin esta opción el shell se abre y sale instantáneamente.

   La opción -t abre una sesión de terminal; sin esta opción no se puede escribir nada en el shell.

Procedimiento

1. Acceda al Red Hat Container Registry utilizando sus credenciales del Portal del Cliente:

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

2. Extrae la imagen del contenedor como root:

   # podman pull registry.redhat.io/rhel8/gcc-toolset-10-toolchain

3. Inicie la imagen del contenedor con un shell interactivo como root:

   # podman run -it registry.redhat.io/rhel8/gcc-toolset-10-toolchain /bin/bash

4. Ejecute las herramientas del conjunto de herramientas GCC como se espera. Por ejemplo, para verificar la versión del compilador gcc, ejecute:

   bash-4.4$ gcc -v
   ...
   gcc version 10.2.1 20200804 (Red Hat 10.2.1-2) (GCC)

5. Para listar todos los paquetes proporcionados en el contenedor, ejecute

   bash-4.4$ rpm -qa