lunes, 2 de octubre de 2017

Mac OS vs. GDB

Desde hace ya bastante tiempo, las herramientas de desarrollo de Mac OS pasaron de usar gcc+gdb (compilador y depurador) a llvm/clang+lldb. El paso a llvm/clang como nuevo compilador no me generó demasiados problemas ya que la linea de comandos de clang es 99% compatible con la de gcc. Pero para el depurador es otra historia. Integrar lldb en ZinjaI como alternativa a gdb implica muchísimos cambios.

Así que por el momento tenemos que instalar gdb "manualmente" para que funcione correctamente la depuración. Pero esto, por motivos de seguridad (creo), es increíblemente complicado. Armé un script para automatizar todo lo que pude automatizar de este proceso, y una página de ayuda donde encontrar las instrucciones para el resto. En este post, un video mostrando el proceso completo, y algunas explicaciones al respecto.

 
Hacer funcionar gdb en ZinjaI implica principalmente 2 cosas: obtener un ejecutable de gdb, y firmarlo. Lo de obtener un ejecutable, se puede hacer descargando los fuentes y compilándolos. Si ya se instalaron las herramientas de xcode, la compilación es simple, solo lleva tiempo. Así que ZinjaI ofrece desde la ayuda un script que descarga y compila gdb sin que el usuario tenga que hacer nada más que un click.

El problema es lo de "firmarlo". Esto parece tener que ver con darle permiso al ejecutable (del depurador) para meterse con otros ejecutables (los programas a depurar). El ejecutable se firma con una llave/certificado. El certificado (hasta donde yo se) solo puede generarlo el usuario manualmente desde un asistente que el sistema tiene para tal fin; no encontré forma de automatizar estos pasos.


Los pasos para generarlo manualmente son muchos y rebuscados. No conozco mucho de Mac OS, ni soy usuario más allá de testear muy básicamente ZinjaI cada tanto, así que hablo con mucho desconocimiento de causa; pero tanta complejidad no parece para nada justificada, sino más bien ridícula.Y a pesar de googlear y googlear, no encontré una serie de pasos más simple/corta que funcione, así que no parece ser problema solo mío.

En definitiva, para generar la llave con la cual firmar al ejecutable, por alguna razón hay que:
  • generarla en la categoría "inicio de sesión"
  • cambiarle algunas propiedades
  • moverla a la categoría "sistema"
  • arrastrarla al escritorio para que genere un archivo ".cer"
  • aplicarle a ese archivo un comando mágico desde la terminal (y luego simplemente borrarlo!)
  • volver el certificado a "inicio de sesión"
  • y finalmente, otra vez desde la terminal, aplicarle ese certificado al ejecutable de gdb
Y en medio de este proceso, nos habrá pedido usuario, clave, y/o huella digital 5 o 6 veces. Y por si fuera poco, las instrucciones estándar terminan con un reinicio del sistema.

Los dos pasos que van desde la terminal, puedo realizarlos mediante el mismo script que automatiza la compilación. Por esto, cuando la compilación termina, el script se queda esperando a que el usuario haga su primer parte, luego aplica el primer comando mágico y se pone a esperar a que el usuario haga su segunda parte, y finalmente aplica el segundo comando mágico. Más aún, hasta trata de evitar la necesidad de reiniciar el sistema matando un servicio para que se reinicie solo. Pero igual queda mucho trabajo para el usuario (más de 10 pasos, y bastante variados).

Si todo sale bien, tendremos un gdb bastante funcional. Solo nos pedirá usuario y clave en la primer depuración, y luego seguirá funcionando sin volver a molestar.  Pero si me preguntan a mi, esto parece un exceso. Si alguien con más conocimiento del tema encuentra una forma más simple, o sabe cómo automatizar algún paso más, bienvenido sea para compartirlo en el foro o en los comentarios. Mientras tanto, paciencia y buena suerte.


1 comentario:

  1. La verdad quedó espectacular, un lujo total.

    ResponderEliminar