Cómo depurar código de un plugins para el VDR?

Antes de nada, me presento ya que soy nuevo en el foro (aunque os sigo desde hace algún tiempo y siempre que puedo)...

Al final he decidido poner esta pregunta aquí porque no sabía muy bien dónde meterlo a pesar de considerarlo como un posible documento de ayuda.

Y ahora paso a explicarme de lo que me gustaría que alguno de los foreros me indicara:

En concreto me gustaría saber si hay algún programa IDE (entorno integrado de desarrollo linux) tipo "CodeLite" donde se pueda cargar el código fuente de un plugins para posteriormente pasar a depurarlo y compilarlo. Y si no es posible, cúal sería el procedimiento para conseguirlo. Yo la verdad es que no estoy muy ducho en programación (tan sólo he programado algo en VB y he visto un poco de Java) pero siempre me ha llamado mucho la atención y nunca es tarde si la dicha es
buena

Pues tienes dos maneras de acerlo.

1. Con printf como se hacia antes, compilando en el PC y ejecutando en el giga directamente. Al final es la mas rapida.

2. Con gdb en remoto. Compilando en el PC, ejecutando un servidor de depuracion y el plugin en el giga y conectandote con el gdb desde el PC al giga. Esto lo he hecho, no era sencillo y no recuerdo muy bien los pasos que segui. Habria que googlear un poco.
Al usar gdb podrias usar IDEs que lo integren.

Muchas gracias zjuanma, de momento voy a probar a ver si consigo algo con las opciones que me has dado. Solamente me queda una duda: visualizando el código de algunos plugins he detectado que algunas líneas apuntan a ficheros contenidos en "/VDR/...". ¿Ese directorio se refiere al código fuente de la versión VDR-1.6.0 o en cambio apunta a VDR-NG-EM? (disculpa mi ignorancia) . Y sí, ya veo que no es tan simplón com VB

Hacen referencia a nuestro VDR-M7x0 que está basado en el VDR 1.4.7 para PC y tiene muchas modificaciones específicas para nuestro equipo.

Muchas gracias. Tomo nota.
He buscado y me aparecen en tu página (http://bittor7x0.googlepages.com/vdr-em) dos descargas:
- Una con versión 0.2 BETA
- Otra con el código fuente de los plugins, así como el de los patchs aplicados

Corrígeme si me equivoco pero supongo que la "versión 0.2 BETA" es la versión VDR 1.4.7 para PC de la que me hablas, y después en la otra descarga (código fuente plugins/patchs) está el código con las modificaciones específicas del m7x0.

Por cierto creo que si quiero debbugear un plugin, al ser éste dependiente del programa principal (vdr) tendré lógicamente que depurar el plugin "arrancando" el vdr previamente. Pero aunque estoy probando con DDD, no acabo de ponerlo en marcha. Y pienso que es porque no tengo configurado un "VDR externo". Me podrías por favor ayudar en esto último?.

Muchas gracias por anticipado y disculpa porque soy consciente de que estoy muy verde en esto.

Esa versión es muy vieja, la actual está aquí:
http://www.assembla.com/wiki/show/VDR-M7x0/Instalaci%C3%B3n_del_VDR-NG-EM#instalacion_linux

Para debugear un plugin no es necesario que uses un VDR externo, usas syslog y luego verás los mensajes en /var/log/messages.

bittor, para depurar usando ddd como el quiere si le hace falta el VDR y el codigo fuente.

Tienes que compilar el vdr y los plugins con -g (si no recuerdo mal) para que meta los simbolos de depuracion y luego tener el codigo fuente accesible para el depurador.

Lo copias en el gigaset lo arrancas y con un gdb compilado tambien para el giga y ejecutando en el giga lo arrancas como servidor y luego con el ddd en el pc te "enganchas" a ese gdb servidor que ejecuta en el giga.

OK, pero el código fuente lo tienes al generar el firmware desde Linux y la versión 0.2 de la que habla es viejísima.

Hasta lo que he leído, creo que lo que dice zjuanma es correcto. Hay que compilar con -g para luego poder hacer el debug. Ahora me queda la duda de qué versión gdb es el que hay que compilar para el giga, ya que lo vi en un foro (gdb compilado para el giga) pero el enlace estaba roto...

el gdb sino recuerdo mal se compila con el propio firmware y si no es porque falta en algun make, pero los fuentes estan.

De todos modos busca "depurar gdb remoto" en google y encontraras muchos links de como se hace.

Antes de ejecutar el make editas el archivo .config y cambias:

Código:

# CONFIG_GDB is not set

por:

Código:

CONFIG_GDB = y

Así ya tendrás el gdb compilado para el giga.

Lo voy a compilar con 'CONFIG_GDB = y' para probar el debug en remoto. A ver qué saco

A propósito bittor, cuando te refieres al syslog supongo que te referirás al que tira el vdr, porque el plugin como no lo tenga implementado supongo que no podré obtener nada de nada...

El syslog no es del VDR, es un demonio que registra eventos y lo puede usar el VDR, sus plugins, lircd, scripts, etc.

Para usarlo en un plugin hay que asegurarse que el archivo que va a registrar mensajes tiene este include:
#include <vdr/config.h>

Después según el nivel de log definido para el VDR saldrán más mensajes o menos.

En nuestra versión Pro el nivel de log por defecto es de 2 (configurado en el parámetro "vdr_options" de /etc/rc.local.conf con "-l 2"), pero puede subirse a 3 para ver los mensajes de depuración.

Luego en el plugin podrás usar
esyslog("mensaje") -> se verá si tiene un nivel de log > 0 (mensajes de error)
isyslog("mensaje") -> se verá si tiene un nivel de log > 1 (mensajes de información)
dsyslog("mensaje") -> se verá si tiene un nivel de log > 2 (mensajes de depuración)

Finalmente los mensajes se escriben en el archivo /var/log/messages

Revisando el código del plugin, no aparece como tal #include , pero en su lugar están utilizando "#include "debug.h"" que a los efectos creo que es lo mismo. Lo único es que la captura lo hace a través de DLOG (para depuración), ELOG (para error), etc. Imagino que está "sobreescribiendo" el método de la clase syslog.

Voy a probar lo que me has dicho (colocando -l 3) en el giga y metiendo algunos DLOG en el plugin para después compilarlo y ver qué me tira...

¿de qué plugin hablas?

Los plugins suelen tener defines para los debugs y es muy facil si no usan el syslog adaptarlos. Dime que plugin estas mirando y que necesitas porque a lo mejor lo he tocado ya o lo he mirado para algo y te puedo ayudar.

yaep. Ya sé que no tiene mucha aceptación pero me he encabezonado con en revisar el problema por el cual no muestra el detalle del programa...

Por cierto, muchas gracias por toda la ayuda que me estáis proporcionando. Se nota que sois unos cracks. Qué envidia (de la sana)

jajaja
ese plugin es enterito mio, mandame un privado detallando todo lo que te pasa.
Y por cierto si usa syslog.

Al final conseguí compilar un firmware con la opción "CONFIG_GDB = y", lo instalo, y no veo por ningún lado el ejecutable. Ahora sí que no entiendo nada porque al compilar me fijé y sí que trató el gdb 6.8 (creo)...

He intentado volver a hacerlo pero llevo varios días que no me compila correctamente y supongo que es por los últimos cambios que se están haciendo. Lo intentaré en breve.

Busca el gdb dentro del directorio "build".

Hubo unos errores en el SVN pero ya están corregidos.
Prueba a usar el make-fw otra vez.

Después de todo el tema de los Alemanes, y los problemas para compilar, por fin he conseguido generar el firmware con la opción que me indicaba bittor ("CONFIG_GDB = y"). Me ha generado un directorio "gdb.build" que lo he copiado en el GIGA pero al lanzar el gdb me da el siguiente error:

line 1: syntax error: unexpected "<"

Imagino que como ya está compilado para el Giga, no hace falta hacer más que copiarlo..
Ahora no sé por dónde tirar.

Y por curiosidad: cómo debugueais el VDR? Mediante DLog y viendo luego los mensajes en /var/logs/?

No he usado nunca gdb, por lo que no puede decirte ni cómo se usa.

Si quieres depurar algo sencillo usas el syslog y luego lo miras en /var/log/messages.

Lee este link http://davis.lbl.gov/Manuals/GDB/gdb_17.html

Todos los binarios del firmware son reducidos con la utilidad sstrip que disminuye bastante su tamaño.
Al parecer programas como gdb, objdump y cualquier otro basado en la librería "bfd" no reconocen los binarios como válidos.

Es un bug de la librería bfd que no han debido corregir.

Para que puedas usar el gdb tienes que editar el Makefile y cambiar

Código:

UCLIBC_STRIP := sstrip

por

Código:

UCLIBC_STRIP := $(UCLIBC_TARGET)-strip

Vuelves a ejecutar el make y los binarios tendrían que ocupar más y ser "usables" por gdb.