¿Cuál es la diferencia entre un paquete RPM debuginfo y reconstruir un paquete con una opción como -g?

¿Cuál es la diferencia entre un paquete RPM debuginfo y reconstruir un paquete con una opción como -g?

Me gustaría alguna aclaración sobre cómo se utilizan los paquetes debuginfo de RPM. Digamos que tengo el paquete vimy encontré un bloqueo. Quiero depurar este fallo, pero gdbrecibo errores por gdbno tener acceso a la información del número de línea. En mi mente tengo 2 opciones:

  1. Instale el paquete debuginfo
  2. Reconstruya e instale vimrpm con CFLAGS, CXXFLAGSy LDFLAGScon -g3o 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
...

información relacionada