Desenvolvendo aplicações C e C++ no RHEL 8

1. Os arquivos fonte são compilados para objetos de arquivos.
2. Os arquivos objetos e bibliotecas estão ligados (incluindo as fontes compiladas anteriormente).

Procedimento

1. Mudança para o diretório contendo o(s) arquivo(s) de código fonte.

2. Execute gcc com a opção -c:

   $ gcc -c source.c another_source.c

   Os arquivos objeto são criados, com seus nomes refletindo os arquivos de código fonte originais: source.c resulta em source.o.

   Nota

   Com o código fonte C, substitua o comando gcc por g para o manuseio conveniente das dependências da Biblioteca Padrão C.

Procedimento

1. Mudança para o diretório contendo o(s) arquivo(s) de código objeto.

2. Rodar gcc:

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

   Um arquivo executável chamado executable-file é criado a partir dos arquivos objeto fornecidos e das bibliotecas.

   Para ligar bibliotecas adicionais, adicione as opções necessárias após a lista de arquivos objeto. Para mais informações, veja Capítulo 3, Usando Bibliotecas com GCC.

   Nota

   Com o código fonte C, substitua o comando gcc por g para o manuseio conveniente das dependências da Biblioteca Padrão C.

Procedimento

1. Crie um diretório hello-c e mude para ele:

   $ mkdir hello-c
   $ cd hello-c

2. Criar arquivo hello.c com o seguinte conteúdo:

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

3. Compilar o código com o GCC:

   $ gcc -c olá.c

   O arquivo objeto hello.o é criado.

4. Vincule um arquivo executável helloworld a partir do arquivo objeto:

   $ gcc hello.o -o helloworld

5. Execute o arquivo executável resultante:

   $ ./helloworld
   Hello, World!

Procedimento

1. Crie um diretório hello-cpp e mude para ele:

   $ mkdir hello-cpp
   $ cd hello-cpp

2. Criar arquivo hello.cpp com o seguinte conteúdo:

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

3. Compilar o código com g :

   $ g -c hello.cpp

   O arquivo objeto hello.o é criado.

4. Vincule um arquivo executável helloworld a partir do arquivo objeto:

   $ g hello.o -o helloworld

5. Execute o arquivo executável resultante:

   $ ./helloworld
   Hello, World!

1. Mude para o diretório que contém seu código.

2. Compilar os arquivos fonte do programa com os cabeçalhos da biblioteca foo:

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

   Substitua header_path por um caminho para um diretório contendo os arquivos de cabeçalho para a biblioteca foo.

3. Ligue o programa com a biblioteca foo:

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

   Substitua library_path por um caminho para um diretório contendo o arquivo libfoo.a.

4. Para executar o programa mais tarde, simplesmente:

   $ ./programa

Procedimento

1. Mude para o diretório com as fontes da biblioteca.

2. Compilar cada arquivo fonte em um arquivo objeto com a opção de código independente de posição -fPIC:

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

   Os arquivos objeto têm os mesmos nomes dos arquivos de código fonte originais, mas sua extensão é .o.

3. Vincular a biblioteca compartilhada a partir dos arquivos objeto:

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

   O número da versão maior é X e o número da versão menor é Y.

4. Copie o libfoo.so.x.y para um local apropriado, onde o linker dinâmico do sistema possa encontrá-lo. No Red Hat Enterprise Linux, o diretório para bibliotecas é /usr/lib64:

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

   Note que você precisa de permissões de root para manipular os arquivos neste diretório.

5. Criar a estrutura symlink para o mecanismo soname:

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

Procedimento

1. Criar arquivos de objetos intermediários com GCC.

   $ gcc -c source_file.c...

   Anexar mais arquivos de origem, se necessário. Os arquivos objeto resultantes compartilham o nome do arquivo, mas use a extensão .o.

2. Transforme os arquivos objeto em uma biblioteca estática (arquivo) usando a ferramenta ar do pacote binutils.

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

   O arquivo libfoo.a é criado.

3. Use o comando nm para inspecionar o arquivo resultante:

   $nm libfoo.a

4. Copie o arquivo estático da biblioteca para o diretório apropriado.

5. Ao vincular-se contra a biblioteca, o GCC reconhecerá automaticamente a partir da extensão do nome do arquivo .a que a biblioteca é um arquivo para vínculo estático.

   $ gcc ... -lfoo...

Procedimento

1. Crie um diretório hellomake e mude para este diretório:

   $ mkdir hellomake
   $ cd hellomake

2. Crie um arquivo hello.c com o seguinte conteúdo:

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

3. Crie um arquivo Makefile com o seguinte conteúdo:

   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)

   Cuidado

   As linhas de receitas Makefile devem começar com o caractere de tabulação! Ao copiar o texto acima da documentação, o processo de cortar e colar pode colar espaços em vez de abas. Se isso acontecer, corrija o problema manualmente.

4. Rodar make:

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

   Isto cria um arquivo executável hello.

5. Execute o arquivo executável hello:

   $ ./hello
   Hello, World!

6. Execute o alvo Makefile clean para remover os arquivos criados:

   $ make clean
   rm -rf hello.o hello

Procedimento

1. Inicie a GDB anexada à aplicação ou biblioteca que você deseja depurar. A GDB reconhece automaticamente as informações de depuração em falta e sugere um comando para executar.

   $ 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. Sair da GDB: digite q e confirme com Enter.

   (gdb) q

3. Execute o comando sugerido pela GDB para instalar os pacotes necessários debuginfo:

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

   A ferramenta de gerenciamento de pacotes dnf fornece um resumo das mudanças, pede confirmação e, uma vez confirmada, baixa e instala todos os arquivos necessários.

4. Caso a GDB não seja capaz de sugerir o pacote debuginfo, siga o procedimento descrito em Seção 7.5, “Obtenção manual de pacotes de debuginfo para uma aplicação ou biblioteca”.

Procedimento

1. Encontre o arquivo executável da aplicação ou biblioteca.

   1. Use o comando which para encontrar o arquivo de aplicação.

      $ which less
      /usr/bin/less

   2. Use o comando locate para encontrar o arquivo da biblioteca.

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

      Se os motivos originais para depuração incluírem mensagens de erro, escolha o resultado onde a biblioteca tem os mesmos números adicionais em seu nome de arquivo que aqueles mencionados nas mensagens de erro. Em caso de dúvida, tente seguir o restante do procedimento com o resultado onde o nome do arquivo da biblioteca não inclui números adicionais.

      Nota

      O comando locate é fornecido pelo pacote mlocate. Para instalá-lo e permitir seu uso:

      # yum install mlocate
      # updatedb

2. Procure por um nome e uma versão do pacote que forneceu o arquivo:

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

   A saída fornece detalhes para o pacote instalado no formato name:epoch-version.release.architecture.

   Importante

   Se esta etapa não produzir nenhum resultado, não é possível determinar qual pacote forneceu o arquivo binário. Há vários casos possíveis:

   • O arquivo é instalado a partir de um pacote que não é conhecido pelas ferramentas de gerenciamento de pacotes em sua configuração current.
   • O arquivo é instalado a partir de um pacote baixado localmente e instalado manualmente. Determinar um pacote adequado debuginfo automaticamente é impossível nesse caso.
   • Suas ferramentas de gerenciamento de pacotes estão mal configuradas.
   • O arquivo não é instalado a partir de nenhum pacote. Em tal caso, não existe o respectivo pacote debuginfo.

   Como os passos seguintes dependem desta, você deve resolver esta situação ou abortar este procedimento. A descrição exata das etapas de solução de problemas está além do escopo deste procedimento.

3. Instale os pacotes debuginfo usando o utilitário debuginfo-install. No comando, use o nome do pacote e outros detalhes que você determinou durante a etapa anterior:

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

1. Encontre o ID do processo (pid) com o comando ps:

   $ ps -C program -o pid h
    pid

   Substituir program por um nome de arquivo ou caminho para o programa.

2. Anexar a GDB a este processo:

   $ gdb -p pid

   Substitua pid por um número de identificação de processo real da saída ps.

1. Use o comando shell GDB para executar o comando ps e encontrar o ID de processo do programa (pid):

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

   Substituir program por um nome de arquivo ou caminho para o programa.

2. Use o comando attach para anexar o GDB ao programa:

   (gdb) anexar pid

   Substituir pid por um número de identificação do processo real da saída ps.

Procedimento

1. Identificar as chamadas do sistema a serem monitoradas.

2. Iniciar strace e anexá-lo ao programa.

   • Se o programa que você deseja monitorar não estiver em execução, inicie strace e especifique o program:

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

   • Se o programa já estiver em execução, encontrar sua identificação de processo (pid) e anexar strace a ele:

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

   • Substituir call pelas chamadas do sistema a serem exibidas. Você pode usar o -e trace=call opção várias vezes. Se omitido, strace exibirá todos os tipos de chamadas do sistema. Consulte a página do manual strace(1) para mais informações.
   • Se você não quiser rastrear nenhum processo bifurcado ou rosca, deixe de fora a opção -f.

3. A ferramenta strace exibe as chamadas do sistema feitas pela aplicação e seus detalhes.

   Na maioria dos casos, uma aplicação e suas bibliotecas fazem um grande número de chamadas e a saída de strace aparece imediatamente, se nenhum filtro para chamadas ao sistema for definido.

4. A ferramenta strace sai quando o programa sai.

   Para encerrar o monitoramento antes da saída do programa rastreado, pressione Ctrl C.

   • Se strace iniciou o programa, o programa termina junto com strace.
   • Se você anexou strace a um programa já em execução, o programa termina juntamente com strace.

5. Analisar a lista de chamadas de sistema feitas pela aplicação.

   • Os problemas de acesso ou disponibilidade de recursos estão presentes no registro como erros de retorno de chamadas.
   • Os valores passados para as chamadas ao sistema e os padrões de seqüências de chamadas fornecem uma visão das causas do comportamento da aplicação.
   • Se a aplicação falhar, as informações importantes estarão provavelmente no final do registro.
   • A saída contém muitas informações desnecessárias. Entretanto, você pode construir um filtro mais preciso para as chamadas de interesse do sistema e repetir o procedimento.

Procedimento

1. Identificar as bibliotecas e funções de interesse, se possível.

2. Iniciar ltrace e anexá-lo ao programa.

   • Se o programa que você deseja monitorar não estiver em execução, inicie ltrace e especifique program:

     $ ltrace -f -l library -e function program

   • Se o programa já estiver em execução, encontrar sua identificação de processo (pid) e anexar ltrace a ele:

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

   • Use as opções -e, -f e -l para filtrar a saída:

     • Forneça os nomes das funções a serem exibidas como function. O -e function pode ser usado várias vezes. Se omitido, ltrace exibe chamadas para todas as funções.
     • Em vez de especificar funções, você pode especificar bibliotecas inteiras com o -l library opção. Esta opção se comporta de forma semelhante à -e function opção.
     • Se você não quiser rastrear nenhum processo bifurcado ou rosca, deixe de fora a opção -f.

     Consulte a página ltrace(1)_ manual para mais informações.

3. ltrace exibe as chamadas da biblioteca feitas pela aplicação.

   Na maioria dos casos, uma aplicação faz um grande número de chamadas e a saída ltrace aparece imediatamente, se nenhum filtro for configurado.

4. ltrace sai quando o programa sai.

   Para encerrar o monitoramento antes da saída do programa rastreado, pressione ctrl C.

   • Se ltrace iniciou o programa, o programa termina junto com ltrace.
   • Se você anexou ltrace a um programa já em execução, o programa termina junto com ltrace.

5. Analisar a lista de chamadas da biblioteca feitas pelo aplicativo.

   • Se a aplicação falhar, as informações importantes estarão provavelmente no final do registro.
   • A saída contém muitas informações desnecessárias. Entretanto, é possível construir um filtro mais preciso e repetir o procedimento.

Procedimento

1. Encontre o ID do processo (pid) do processo que você deseja monitorar:

   $ ps -aux

2. Execute SystemTap com o script strace.stp:

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

   O valor de pid é a identificação do processo.

   O script é compilado em um módulo do kernel, que é então carregado. Isto introduz um pequeno atraso entre a entrada do comando e a obtenção da saída.

3. Quando o processo realiza uma chamada ao sistema, o nome da chamada e seus parâmetros são impressos no terminal.
4. O script sai quando o processo termina, ou quando você pressiona Ctrl C.

Procedimento

1. Defina o ponto de captação:

   (gdb) catch syscall syscall-name

   O comando catch syscall define um tipo especial de ponto de parada que interrompe a execução quando o programa executa uma chamada ao sistema.

   O syscall-name especifica o nome da chamada. Você pode especificar vários pontos de captura para várias chamadas de sistema. Deixando de fora o syscall-name faz com que a GDB pare em qualquer chamada ao sistema.

2. Iniciar a execução do programa.

   • Se o programa ainda não começou a ser executado, inicie-o:

     (gdb) r

   • Se a execução do programa for interrompida, retomá-la:

     (gdb) c

3. A GDB suspende a execução depois que o programa executa qualquer chamada de sistema especificada.

Procedimento

1. Defina o ponto de captação:

   (gdb) sinal de captura signal-type

   O comando catch signal estabelece um tipo especial de ponto de parada que interrompe a execução quando um sinal é recebido pelo programa. O signal-type especifica o tipo de sinal. Use o valor especial 'all' para capturar todos os sinais.

2. Deixe o programa funcionar.

   • Se o programa ainda não começou a ser executado, inicie-o:

     (gdb) r

   • Se a execução do programa for interrompida, retomá-la:

     (gdb) c

3. A GDB interrompe a execução depois que o programa recebe qualquer sinal especificado.

Procedimento

1. Para ativar as lixeiras do núcleo, certifique-se de que o arquivo /etc/systemd/system.conf contenha as seguintes linhas:

   DumpCore=yes
   DefaultLimitCORE=infinity

   Você também pode adicionar comentários descrevendo se estas configurações estavam presentes anteriormente, e quais eram os valores anteriores. Isto permitirá que você reverta estas mudanças mais tarde, se necessário. Os comentários são linhas que começam com o caracter #.

   A alteração do arquivo requer acesso em nível de administrador.

2. Aplique a nova configuração:

   # daemon-reexec systemctl

3. Remover os limites para os tamanhos de despejo do núcleo:

   # ulimit -c ilimitado

   Para reverter esta mudança, execute o comando com valor 0 em vez de unlimited.

4. Instale o pacote sos que fornece o utilitário sosreport para a coleta de informações do sistema:

   # yum instalar sos

5. Quando uma aplicação trava, um depósito central é gerado e tratado por systemd-coredump.

6. Criar um relatório SOS para fornecer informações adicionais sobre o sistema:

   # sosreport

   Isto cria um arquivo .tar contendo informações sobre seu sistema, tais como cópias de arquivos de configuração.

7. Localizar e exportar o despejo do núcleo:

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

   Se a aplicação falhou várias vezes, a saída do primeiro comando lista mais lixeiras de núcleo capturado. Nesse caso, construir para o segundo comando uma consulta mais precisa usando as outras informações. Consulte a página do manual coredumpctl(1) para obter detalhes.

8. Transferir o despejo do núcleo e o relatório SOS para o computador onde a depuração será realizada. Transferir também o arquivo executável, se for conhecido.

   Importante

   Quando o arquivo executável não é conhecido, a análise subseqüente do arquivo principal o identifica.

9. Opcional: Remover o despejo do núcleo e o relatório SOS depois de transferi-los, para liberar espaço em disco.

Procedimento

1. Para identificar o arquivo executável onde ocorreu a falha, execute o comando eu-unstrip com o arquivo dump do 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

   A saída contém detalhes para cada módulo em uma linha, separados por espaços. As informações estão listadas nesta ordem:

   1. O endereço de memória onde o módulo foi mapeado
   2. A parte interna do módulo e onde na memória foi encontrado
   3. O nome do arquivo executável do módulo, exibido como - quando desconhecido, ou como . quando o módulo não tiver sido carregado de um arquivo
   4. A fonte de informações de depuração, exibida como um nome de arquivo quando disponível, como . quando contido no próprio arquivo executável, ou como - quando não presente em absoluto
   5. O nome da biblioteca compartilhada (soname) ou [exe] para o módulo principal

   Neste exemplo, os detalhes importantes são o nome do arquivo /usr/bin/sleep e o build-id 2818b2009547f780a5639c904cded443e564973e na linha que contém o texto [exe]. Com estas informações, é possível identificar o arquivo executável necessário para a análise do despejo do núcleo.

2. Obtenha o arquivo executável que falhou.

   • Se possível, copie-a do sistema onde ocorreu o acidente. Use o nome do arquivo extraído do arquivo principal.

   • Você também pode usar um arquivo executável idêntico em seu sistema. Cada arquivo executável construído no Red Hat Enterprise Linux contém uma nota com um valor de build-id único. Determine o build-id dos arquivos executáveis relevantes disponíveis localmente:

     $ eu-readelf -n executable_file

     Use estas informações para comparar o arquivo executável no sistema remoto com sua cópia local. O build-id do arquivo local e o build-id listado no lixão central devem coincidir.

   • Finalmente, se o aplicativo for instalado a partir de um pacote RPM, você pode obter o arquivo executável a partir do pacote. Use a saída sosreport para encontrar a versão exata do pacote necessário.
3. Obtenha as bibliotecas compartilhadas utilizadas pelo arquivo executável. Use os mesmos passos que para o arquivo executável.
4. Se o aplicativo for distribuído como um pacote, carregue o arquivo executável no GDB, para exibir dicas de pacotes de debuginfo em falta. Para mais detalhes, veja Seção 7.4, “Obtendo pacotes de debuginfo para uma aplicação ou biblioteca usando GDB”.

5. Para examinar o arquivo principal em detalhes, carregue o arquivo executável e o arquivo principal de despejo com a GDB:

   $ gdb -e executable_file -c core_file

   Outras mensagens sobre arquivos ausentes e informações de depuração ajudam a identificar o que está faltando para a sessão de depuração. Retornar à etapa anterior, se necessário.

   Se a informação de depuração da aplicação estiver disponível como um arquivo em vez de um pacote, carregue este arquivo no GDB com o comando symbol-file:

   (gdb) arquivo-símbolo program.debug

   Substituir program.debug pelo nome do arquivo real.

   Nota

   Talvez não seja necessário instalar as informações de depuração para todos os arquivos executáveis contidos no lixão principal. A maioria destes arquivos executáveis são bibliotecas utilizadas pelo código da aplicação. Estas bibliotecas podem não contribuir diretamente para o problema que você está analisando, e você não precisa incluir informações de debugging para eles.

6. Use os comandos da GDB para inspecionar o estado da aplicação no momento em que ela caiu. Ver Capítulo 8, Aplicação de inspeção do Estado Interno com a GDB.

   Nota

   Ao analisar um arquivo principal, a GDB não é anexada a um processo em execução. Os comandos para controlar a execução não têm efeito.

Procedimento

1. Encontre o PID do processo pendurado, baseado em uma parte conhecida do nome do arquivo executável:

   $ pgrep -a executable-name-fragment

   Este comando irá emitir uma linha na forma

   PID command-line

   Use o valor command-line para verificar se o PID pertence ao processo pretendido.

   Por exemplo:

   $ pgrep -a bc
   5459 bc

2. Enviar um sinal de aborto para o processo:

   # matar -ABRT PID

3. Verifique se o núcleo foi capturado por coredumpctl:

   Lista de coredumpctl de dólares PID

   Por exemplo:

   $ 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. Examinar ou usar o arquivo principal conforme necessário.

   Você pode especificar o despejo do núcleo pelo PID e outros valores. Consulte a página do manual coredumpctl(1) para mais detalhes.

   • Para mostrar detalhes do arquivo principal:

     $ coredumpctl info PID

   • Para carregar o arquivo central no depurador GDB:

     $ coredumpctl debug PID

     Dependendo da disponibilidade de informações de depuração, a GDB sugerirá comandos para execução, como por exemplo:

     Falta de debuginfos separados, uso: dnf debuginfo-instalar bc-1.07.1-5.el8.x86_64

     Para mais detalhes sobre este processo, ver Seção 7.4, “Obtendo pacotes de debuginfo para uma aplicação ou biblioteca usando GDB”.

   • Exportar o arquivo principal para processamento posterior em outro lugar:

     $ coredumpctl dumpl PID > /path/to/file_for_export

     Substitua /path/to/file_for_export pelo arquivo onde você quer colocar o despejo do núcleo.

Procedimento

1. Descubra a identificação do processo (pid). Use ferramentas como ps, pgrep, e top:

   $ ps -C some-program

2. Despeje a memória deste processo:

   $ gcore -o filename pid

   Isto cria um arquivo filename e despeja nele a memória do processo. Enquanto a memória está sendo despejada, a execução do processo é interrompida.

3. Após a conclusão do despejo do núcleo, o processo retoma a execução normal.

4. Criar um relatório SOS para fornecer informações adicionais sobre o sistema:

   # sosreport

   Isto cria um arquivo de alcatrão contendo informações sobre seu sistema, tais como cópias de arquivos de configuração.

5. Transferir o arquivo executável do programa, a lixeira do núcleo e o relatório SOS para o computador onde será realizada a depuração.
6. Opcional: Remover o despejo do núcleo e o relatório SOS depois de transferi-los, para liberar espaço em disco.

Procedimento

1. Defina a GDB para ignorar as configurações no arquivo /proc/PID/coredump_filter:

   (gdb) definir o filtro de uso-corpo-corpo

2. Defina a GDB para ignorar a bandeira da página de memória VM_DONTDUMP:

   (gdb) colocar os mapeamentos excluídos do lixão em

3. Despeje a memória:

   (gdb) gcore core-file

   Substitua core-file pelo nome do arquivo onde você quer despejar a memória.

Procedimento

1. Liste os pacotes disponíveis em GCC Toolset versão N:

   Lista de yum disponível gcc-toolset-N-\*

2. Para instalar qualquer um destes pacotes:

   # instalação do yum package_name

   Substituir package_name por uma lista de pacotes a serem instalados, separados por espaço. Por exemplo, para instalar os pacotes gcc-toolset-9-gdb-gdbserver e gcc-toolset-9-gdb-doc:

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

Procedimento

1. Acesse o Red Hat Container Registry usando suas credenciais do Portal do Cliente:

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

2. Puxe uma imagem de contêiner que você precisa, executando um comando relevante como raiz:

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

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

   Nota

   Nas versões RHEL 8.1 e posteriores, você pode configurar seu sistema para trabalhar com containers como um usuário não-root. Para obter detalhes, veja Running containers como root ou rootless.

3. Opcional: Verifique se o puxão foi bem sucedido executando um comando que lista todas as imagens de contêineres em seu sistema local:

   # imagens do podman

4. Execute um contêiner lançando uma concha de bash dentro de um contêiner:

   # podman run -it image_name /bin/bash

   A opção -i cria uma sessão interativa; sem esta opção, a casca se abre e sai instantaneamente.

   A opção -t abre uma sessão terminal; sem esta opção você não pode digitar nada na concha.

Procedimento

1. Acesse o Red Hat Container Registry usando suas credenciais do Portal do Cliente:

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

2. Puxe a imagem do recipiente como raiz:

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

3. Lançar a imagem do recipiente com uma concha interativa como raiz:

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

4. Execute as ferramentas do GCC Toolset como esperado. Por exemplo, para verificar a versão do compilador gcc, execute:

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

5. Para listar todas as embalagens fornecidas no contêiner, execute:

   bash-4,4$ rpm -qa