
Me gustaría alguna aclaración sobre cómo se utilizan los paquetes debuginfo de RPM. Digamos que tengo el paquete vim
y encontré un bloqueo. Quiero depurar este fallo, pero gdb
recibo errores por gdb
no tener acceso a la información del número de línea. En mi mente tengo 2 opciones:
- Instale el paquete debuginfo
- Reconstruya e instale
vim
rpm conCFLAGS
,CXXFLAGS
yLDFLAGS
con-g3
o algo similar.
Recientemente probé la opción n.° 1 y todavía recibo algunos errores sobre símbolos faltantes en gdb, lo que generó esta pregunta mientras hacía algunas suposiciones sobre qué son los paquetes debuginfo y cómo se usan. ¿Podría explicar las diferencias entre las opciones 1 y 2 que enumeré anteriormente o, en caso de que me equivoque, cómo lograrlo correctamente?
Respuesta1
Recientemente probé la opción n.° 1 y todavía recibo algunos errores sobre símbolos faltantes en gdb, lo que generó esta pregunta mientras hacía algunas suposiciones sobre qué son los paquetes debuginfo y cómo se usan.
Es posible que el bloqueo no se produzca en la aplicación en sí, sino en glibc o en cualquier otra biblioteca de la que dependa vim. Lo que significa que debe instalar paquetes debuginfo para todas las bibliotecas relevantes.
Lo que también significa que construir vim a partir de fuentes probablemente generará el mismo problema: algunos símbolos de depuración no se resuelven. Además, si construye un paquete usted mismo, sus indicadores de compilación serán diferentes a los utilizados por Fedora y entonces puede que obtenga o no el mismo bloqueo.
Respuesta2
@Artem es correcto: necesita tener información de depuración de todas las dependencias transitivas.
Puede resultar doloroso encontrarlos a todos. Puedes hacerlo fácilmente usando ABRT ( dnf install abrt
). Cuando algo falla, ABRT lo registra. Por ejemplo, en mi 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
...