
Gostaria de alguns esclarecimentos sobre como os pacotes debuginfo do RPM são usados. Digamos que eu tenha o pacote vim
e encontrei uma falha. Quero depurar esta falha, mas gdb
estou recebendo erros sobre gdb
não ter acesso às informações do número da linha. Na minha cabeça, tenho 2 opções:
- Instale o pacote debuginfo
- Recrie e instale o
vim
rpm comCFLAGS
,CXXFLAGS
eLDFLAGS
with-g3
ou 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
...