Qual é a diferença entre um pacote RPM debuginfo e reconstruir um pacote com uma opção como -g?

Qual é a diferença entre um pacote RPM debuginfo e reconstruir um pacote com uma opção como -g?

Gostaria de alguns esclarecimentos sobre como os pacotes debuginfo do RPM são usados. Digamos que eu tenha o pacote vime encontrei uma falha. Quero depurar esta falha, mas gdbestou recebendo erros sobre gdbnão ter acesso às informações do número da linha. Na minha cabeça, tenho 2 opções:

  1. Instale o pacote debuginfo
  2. Recrie e instale o vimrpm com CFLAGS, CXXFLAGSe LDFLAGSwith -g3ou algo semelhante.

Recentemente tentei a opção nº 1 e ainda recebo alguns erros sobre símbolos ausentes no gdb, o que gerou essa pergunta enquanto eu fazia algumas suposições sobre o que são os pacotes debuginfo e como eles são usados. Você poderia explicar as diferenças entre as opções 1 e 2 listadas acima ou, caso eu esteja incorreto, como fazer isso corretamente?

Responder1

Recentemente tentei a opção nº 1 e ainda recebo alguns erros sobre símbolos ausentes no gdb, o que gerou essa pergunta enquanto eu fazia algumas suposições sobre o que são os pacotes debuginfo e como eles são usados.

A falha pode não estar no aplicativo em si, mas, por exemplo, na glibc ou em qualquer outra biblioteca da qual o vim depende. O que significa que você deve instalar pacotes debuginfo para todas as bibliotecas relevantes.

O que também significa que construir o vim a partir de fontes provavelmente levará ao mesmo problema: alguns símbolos de depuração não são resolvidos. Além disso, se você mesmo construir um pacote, seus sinalizadores de compilação serão diferentes daqueles usados ​​pelo Fedora e então você poderá ou não obter o mesmo travamento.

Responder2

@Artem está correto - você precisa ter informações de depuração de todas as dependências transitivas.

Pode ser doloroso encontrar todos eles. Você pode facilitar isso usando ABRT ( dnf install abrt). Quando algo trava, é registrado pela ABRT. Por exemplo, no meu sistema:

$ abrt     
071eb9c 1x /usr/libexec/mysqld 2020-06-24 00:55:09
7552a02 1x mariadb 2020-06-26 15:37:45
$ abrt backtrace 071eb9c
Problem has no backtrace
Start retracing process? [y/N] y
Upload core dump and perform remote retracing? (It may contain sensitive data). If your answer is 'No', a stack trace will be generated locally. Local retracing requires downloading potentially large amount of debuginfo data [y/N] n
Local retracing
Analyzing coredump 'coredump'
Cleaning cache...
Cache cleaning has finished
...

informação relacionada