No sé si esto va a ayudar, pero hay una buena serie de escribir depuradores y extensiones de código administrado en:
antes de empezar a escribir ningún código depurador, pensé ayudaría a revisar rápidamente la infraestructura del depurador .NET que está disponible como y el diseño del depurador de línea de comandos MDbg. Tenga en cuenta que mi comprensión de de este material es bastante rudimentaria: Mike Stall es "da hombre" si está buscando un blogger depurador de .NET para leer.
El CLR proporciona una serie de APIs no administrados para cosas como alojamiento el CLR, leer y escribir metadatos CLR y - más relevante para nuestra discusión actual - depuración, así como la lectura y la escritura depurador símbolos. Estas API están expuestas como objetos COM. La API de depuración de CLR le permite hacer todas las cosas que cabría esperar hacer en un depurador: adjuntar a procesos (en realidad, dominios de aplicación), crear puntos de interrupción, paso a paso, etc. Por supuesto, una API no administrada, , no está disponible para ser utilizada desde IronPython. Afortunadamente, MDbg envuelve esta API no administrada para nosotros, haciéndola disponible para cualquier lenguaje administrado , incluido IronPython.
El diseño básico de MDBG se parece a esto:
imagen
En la parte inferior es la asamblea “en bruto”, que contiene la definición de C# de la API depurador no administrado - básicamente cualquier cosa que empieza con ICorDebug e ICorPublish. Raw también define algunos de los API de metadatos, , ya que así es como se expone la información del tipo al depurador.
El siguiente nivel es el ensamblado "corapi", al que me refiero como la API de depurador administrado de bajo nivel . Esta es una capa bastante delgada que traduce el paradigma no gestionado en algo más aceptable para los desarrolladores de código administrado . Por ejemplo, los enumeradores COM como ICorDebugAppDomainEnum están expuestos como tipos de IEnumerable. Además, la interfaz de devolución de llamada administrada se expone como eventos .NET. No es perfecto - el código está escrito en el estilo C# 1.0 por lo que no hay genéricos o rendimientos.
Donde corapi es la API de bajo nivel, "mdbgeng" es la API de depurador administrada de alto nivel . Como era de esperar, ajusta la API de bajo nivel y proporciona implementaciones automáticas de operaciones comunes. Por ejemplo, esta capa mantiene una lista de puntos de interrupción para que pueda crearlos antes de que se haya cargado el ensamblaje pertinente. Luego, cuando los ensamblados están cargados en , pasan por la lista de puntos de interrupción independientes para ver si se puede enlazar . También es esta capa la que crea automáticamente el punto de entrada principal del punto de entrada .
Finalmente, en la parte superior tenemos la aplicación MDbg misma, así como cualquier extensión MDbg (representada por ... en el diagrama de arriba). El ensamblado mdbgext define los tipos compartidos entre MDbg.exe y los ensamblados de extensión . MDbg tiene algunas extensiones geniales, incluida una extensión de IronPython , pero por ahora estoy centrado en construir algo tan ligero como sea posible, así que voy a renunciar a un mecanismo de extensibilidad , al menos por ahora.
Mi prototipo inicial se escribió en contra de la API de alto nivel. Hay fueron dos problemas con este enfoque. La primera es que no hay compatibilidad con para Just My Code en la API de alto nivel. Como mencioné en mi última publicación de , el soporte de JMC es fundamental para este proyecto. Agregar el soporte de JMC no es difícil, pero estoy tratando de hacer los menos cambios posibles al origen de MDbg, ya que no estoy interesado en bifurcar y manteniendo ese código. En segundo lugar, mientras que la API de bajo nivel proporciona una API basada en eventos (OnModuleLoad, OnBreakpoint, OnStepComplete, etc.), la API de alto nivel proporciona una API de bucle más orientada a la consola. Encontré la API controlada por eventos para que sea más limpia para trabajar y creo que funcionará mejor si alguna vez construyo una versión de GUI de ipydbg. Así que he decidido a trabajar contra la API de bajo nivel (también conocido como corapi).
He mencionado anteriormente que no quería cambiar la fuente MDbg, pero I hizo un pequeño cambio. La separación de corapi y raw en dos conjuntos separados es un artefacto obsoleto de una versión anterior de MDbg. Así que decidí combinar estos dos en un solo ensamble llamado CorDebug. Además de algunos simples atributos de limpieza a nivel de ensamblaje para hacer posible un solo ensamblaje, no he cambiado el código fuente en absoluto.
Gracias. Había visto MDbg, pero no pude compilar la extensión de python). Esto parece una especie de root, porque es un depurador independiente y me gustaría conectarme al Visual Studio Debugger. Por desgracia, creo que voy a perder este :( –