FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
|||
|
|||
urgando las VMTs
En este otro hilo, Al González hizo algunos planteamientos que involucraban las famosas táblas de métodos virtuales (VMT's a partir de ahora).
No está muy claro este tema ya que no hay documentación oficial (al menos no la conozco). Lo poco que se conoce es por el Unit System.pas y por lo que algunos programadores han investigado haciendo un poco de ingeniería inversa. Sé que no es bueno andar por lugares tan oscuros como la VMT ya que no sólo hay poco información sino que son muy suceptibles a los cambios sin aviso previo (ni posterior)... De todos modos, muchas veces no hay otra opción. Cuando es así, no queda otra que manejarse con cautela y tener en cuenta las diferencias entre versiones. De hecho, en la versión 2009 se han introducido modificaciones en la VMT... A continuación pongo alguno links que tenía agendados y que estaban esperando a este momento. http://hallvards.blogspot.com/2004/0...id-object.html http://hallvards.blogspot.com/2006/0...structure.html http://hallvards.blogspot.com/2006/0...vmt-calls.html http://hallvards.blogspot.com/2007/0...s-part-ii.html Ya bien empapados en el tema vamos a lo nuestro: Miré código que tenía, algo de Hallvards, algo de GExperts y algo de JCL y terminé con lo siguiente: Tenía un unit dedicado al RTTI así que ustedes pueden tener uno llamado RttiUtils.pas o como prefieran. lo que nos compete va a continuación:
La respuesta la pregunta de Al se responde con la función GetVirtualMethodCount... aunque, como es de esperar, sólo devuelve los métodos declarados con la directiva "virtual", para los que estén declarados con "dinamic" ya es otro asunto. A propósito, los métodos virtuales y abstractos (sin implementación por decirlo de algún modo), apuntan (tal como lo decía Al), a la función _AbstractError pero indirectamente... o sea que se puede hookear. El puntero a interceptar está (como no podía ser de otra manera) en el System.pas: AbstractErrorProc: procedure; { Abstract method error handler } Allí, entonces, podremos colgar nuestra propia rutina para manejar el error, e inclusive llamar desde allí a la original. sólo bastará declarar la función... procedure CustomAbastractError; begin raise EAbstractError.Create('my custom abstract error'); end; y asignarla: AbstractErrorProc := CustomAbastractError; Última edición por poyo fecha: 31-01-2009 a las 00:07:38. Razón: errores |
#2
|
|||
|
|||
para tener en cuenta
me olvidaba de algo importantísimo:
el código que puse arriba es para Delphi 2009... En esta versión a la vmt han tocado. el system.pas dice:
entonces, para versiones anteriores, al record TVmt hay que comentarle lo siguente: equals : pointer; GetHashCode : pointer; ToString : pointer; como verán arriba, hay unas cosas con offset positivo que todavía no las pusimo en el TVmt... también desconozco que son los punteros nuevos. se escuchan sugerencias |
#3
|
||||
|
||||
¡Chanfle!
Ese tipo de cosas siempre han sido mis mayores motivaciones para usar nuevas versiones de Delphi (que ribbon controls, ni qué ocho cuartos ). Nada más de pensar que podría estar palpando esa nueva unidad System.pas... No he probado la función GetVirtualMethodCount que pusiste, pero dudo que pueda funcionar en Delphi 7. Ayer estuve haciendo algunas pruebas con ésta versión y no hay un marcador seguro que señale la terminación de la VMT. Por cierto, esta es la documentación oficial que viene en la propia ayuda en esa y otras versiones anteriores: Cita:
(NOTA: La directiva deprecated señala que esas constantes están cayendo en desuso, más no las entradas de VMT que representan). Cita:
Algo curioso es que todos los métodos abstractos cuentan con su código máquina particular, que es simplemente un salto a la función _AbstractError. O sea que cada método abstracto tiene una dirección de memoria única (como cualquier otro tipo de rutina). Sin embargo, para estos casos, esas direcciones no son guardadas en las entradas de la VMT, sino que éstas almacenan la dirección de memoria de _AbstractError (una VMT con tres métodos abstractos contiene tres entradas de valor idéntico: la dirección de _AbstractError). ¿Entonces por qué genera el compilador código máquina particular con cada método abstracto? Tal parece que sólo para que tengan "identidad propia" a la hora de usarlos como valores procedimentales (@TClase.Metodo). Esto de las entradas puntero a _AbstractError es lo que puede ayudar a saber, VMT mediante, si un método es abstracto o no, apoyándonos con ensamblador y el operador especial VMTOFFSET. Cita:
Y aún más, ahora que recordé el asunto de las interfaces, creo que los métodos con que una clase las implementa son guardados también como entradas en desplazamientos positivos de la VMT. Según la propia ayuda, el operador VMTOFFSET también sirve con métodos de interfaces implementadas por la clase. Habría que hacer algunas pruebas para ver si esto último complicaría más el asunto en Delphi 7. Nos vemos pronto, un saludo. Al González. Última edición por Al González fecha: 31-01-2009 a las 04:25:41. |
#4
|
|||
|
|||
Gracias Al por el pedazo de documentación. Siempre había tenido la sospecha (aunque nunca la había confirmado) de que las instancias comparten la VMT y NO poseen una copia para sí.
Cita:
Cita:
Según lo que he visto, todos lo resuelven así. No lo he visto implementado de ninguna otra manera... ni se me ocurre como. Y sí... es un poco turbio, pero al menos a mí me funciona. Creo que debería funcionar en versiones anteriores también, pues se viene usando desde hace mucho. -------- Con respecto a _AbstractError, tienes absoluta razón! Apuntan allí y desde allí se fija si está asignado AbstractErrorProc y, si es así, la llama, sino, sigue con "_RunError", rutina famosa que muestra los cartelos "Runtime Error" y luego termina en la función Halt0 (que se encarga de terminar la aplicación). debo ser la falta de sueño, de ansiolíticos o el exceso de horas en la máquina! (o la suma de todo. jejejeje) Estuve investigando algo más... algo de eso ya me había cruzado. En en INITIALIZATION del SysUtils.pas se llama (entre otras cosas) a el procedure InitExceptions que se encarga de inicializar la variable AbstractErrorProc del System.pas (y así también de otros errores como ser assert). El manejador de errores de Abstracción es sencillo: procedure AbstractErrorHandler; begin raise EAbstractError.CreateRes(@SAbstractError); end; la asignación también pero lo que me llama la atención son unos comentarios que hay alrededor de tal asignación y el IFNDEF: {$IFNDEF PC_MAPPED_EXCEPTIONS} // We don't hook this under PC mapped exceptions, because // we have no idea what the parameters were to the procedure // in question. Hence we cannot hope to unwind the stack in // our handler. Since we just throw an exception from our // handler, that pretty much rules out using this without // exorbitant compiler support. If you do hook AbstractErrorProc, // you must make sure that you never throw an exception from // your handler if PC_MAPPED_EXCEPTIONS is defined. AbstractErrorProc := @AbstractErrorHandler; {$ENDIF} Supongo que PC_MAPPED_EXCEPTIONS se trata de algo heredado del kylix y su compatibilidad con linux... Cita:
A ver si comprendo: una entrada de una función virtual en una VMT, si esta es abtracta, apuntará a _AbstractError. Cada Método Abstracto tiene un dirección de memoria particular (corresponfiende al Offset dentro de un array de punteros a métodos, no?). La pregunta es por qué hay un elementos en la el array que no están implementados? (es decir, apuntan a _AbstractError)? Siguiendo con la experimentación, querer reemplazar el puntero de un método virtúal de la VMT de la suguiente manera: vmt^.UserDefinedVirtuals[x] := @TForm1.MyMethod; me di cuenta de que no se podía por algo... ARROJABA UNA EXCEPCION! Tras de mirar y mirar si estaba haciendo algo mal, caí en que los Administradores de Memoria (memory managers) de los sistemas operativos que trabajan con microprocesadores que operan en modo protegido, marcan a las páginas de memoria con atributos especiales haciendo que estas se puedan (o no) leer, escribir y/o ejecutar. Claro que todo esto depende del microprocesador y/o sistema operativo... en la actualidad creo que ya todos los microsprocesadores lo soportan y el windows lo viene soportando desde hace rato... no tengo idea. La cuestión es que implementé una función que se encarga de desproteger la vmt y otra que vuelve a protegerla, para dejarla todo como estaba... bueno, casi Otra duda surge de acá: Qué pasaría si el DEP esta activado? Nota: Data Execution Prevention, es algo que se agregó a partir del SP2 del WinXP. Claro que el micro lo tiene que soportar. pd: urgar va con H... lo puse en el título y está mal. Se podrá cambiar? pd2: Adjunto RttiUtils.pas |
#5
|
||||
|
||||
¡Hola Poyo!
Viendo este hilo de Aeff, me vino a la mente que podría existir una manera de sustituir un método virtual por otro método, para casos como ese, donde estando ya un vasto árbol de clases definido, la derivación de clases sería una solución poco efectiva (si el compilador soportara herencia insertada, otro gallo cantaría ). Entonces recordé que habías mencionado algo sobre sustituir entradas de la VMT: Cita:
Seguramente ya habrás hecho algo similar. Pero, como podrás apreciar en el ejemplo, el principal problema es que no todas las llamadas a métodos virtuales son late binding, es decir, aquellas donde el programa determina en tiempo de ejecución a qué rutina va a saltar revisando primero de qué clase es el objeto. ¿Cuáles llamadas a métodos virtuales son resueltas en tiempo de compilación (realizadas "estáticamente")? Particularmente las que usan la palabra reservada Inherited, y también las que se llevan a cabo mediante variables procedimentales. Entonces, creo que la utilidad práctica de sustituir una entrada VMT de método virtual sería aplicable, básicamente, a aquellos casos donde ya existen varias clases derivadas de la clase que implementa el método a sustituir, pero ninguna de esas clases descendientes ha redefinido dicho método, o, si alguna lo ha hecho, no usa Inherited o no nos interesa que para ella se ejecute el código original (y, claro está, no queremos o no podemos modificar el código fuente de la clase ancestro en cuestión). Cita:
El camino que seguirá el programa es distinto, dependiendo de si el enlace de llamada al método virtual es estático o tardío (late binding). Con Inherited y variables procedimentales, saltará a la dirección del método abstracto sin consultar la VMT; mientras que con una llamada tipo "Objeto.Método" sí leerá la entrada respectiva de la VMT. ¿Interesante no? En cuanto a la función GetVirtualMethodCount, aún no me queda claro en qué se basa ésta para determinar que ha encontrado el fin de la VMT. El código, aún con comentarios, me resulta un poco confuso. Insisto en que tiene que haber una especie de marca o dato indicativo seguro en el cual pueda basarse la función para saber dónde termina la lista de entradas de la VMT, puesto que el tamaño de cada VMT es variable y, que yo sepa, no hay ningún lugar donde esté señalado el tamaño que tiene. O bien una regla de almacenamiento que no estoy percibiendo... Saludos. Al González. |
#6
|
|||
|
|||
Esto en vez de divertido parece ser un dolor de cabeza... jajajaja
Cada vez que aclaramos, oscurece... y termina siendo más estático de lo que me imaginaba. Ahora entiendo algunas limitaciones de los ClassHelpers. Hasta allí llegan... Para implementar herencia insertada o cosas por el estilo creo que los muchachos de codegear deberían de replantearse una buena parte del asunto. un arduo trabajo aunque, lo más difícil es decidirse a comenzar, no? Una vez que estás en camino casi nunca resulta tan complicado como parececía antes de empezar. No, no había hecho la prueba de reemplazar un método de la VMT y luego llamarlo mediante "inherited"... daba por hecho que esta función iba a buscar la VMT del ClassParent y allí resolvía el puntero a la función, pero resultó no ser así. es una lástima porque se hubiesen podido hacer cosas interesantes. Es muy peciliar el uso que se hace de la VMT. Parece ser que al final de cuentas termina siendo sólo realmente útil para la persistencia y alguna que otra cosita más. Con respecto a las llamadas (donde simplemente se hace un Jump): ... jmp dword prt [$XXXXXXXX] mov eax, eax ... Se me hace que estas direcciones de memoria (que apuntan a las funciones en cuestión) son llenadas en runtime en el LoadPackage mediante GetProcAddress. Algo similar pasa con las variables globales cuando son compiladas para usarse dinámicamente. En mi caso había una "tabla" de que saltos a funciones en los cuales estaban todos estos juntos (con rtl en runtime): abstract error tobject.initinstance tobject.freeinstance tobject.free tobject.equals tobject.gethashcode tobject.tostring tobject.dispatch handlefinally startexe halt0 registermodule finalization Volviendo a GetVirtualMethodCount, a mí tampoco me queda del todo claro. :S Sí cómo es obtenido y eso, pero exactamente porqué. Sé que juegan con punteros. Toman el final de la vmt, luego recorren las entradas buscando las direcciones de los punteos, buscan la más alta, hacen la diferencia, dividen por 4 y les da. (más magia negra!) pero porqué esos punteros y no otros? A mi entender, se basan en información que no he encontrado o no está disponible (en el orden en que es asignada (alloc) la memoria de la tabla de métodos virtuales). Es decir, SABEN con seguridad que hay un puntero que se contiguo a la tabla de métodos virtuales. |
#7
|
||||
|
||||
Cita:
Tal parece que la estructura de la VMT finaliza con el ShortString que contiene el nombre de la clase, lo cual es bastante lógico. Es información intrínseca de la VMT, pero, como es de longitud variable, en el desplazamiento vmtClassName sólo guardan un puntero a ese ShortString, así la estructura inicial permanece uniforme para todas las VMTs y rematan estas estructuras con el propio nombre de la clase. Es una técnica bastante usual colocar al final de una estructura las partes que pueden ser de tamaño variable. No lo he probado, pero entonces con esto sí podríamos saber cuántas entradas de métodos virtuales y de métodos de interfaces tiene una VMT. Ahora la pregunta sería, ¿cómo distinguir unas de otras? Y algo más de considerar: la función GetVirtualMethodCount que enlacé parece ser de una versión más reciente que la mostrada inicialmente, y en ella el algoritmo es significativamente distinto. Habrá que hacer algunas pruebas adicionales en un rato libre... Espero te alivies de los dolores de cabeza, Poyo, tómalo con calma. Son simples bytes. Me entusiasma participar con los colegas en este tipo de disertaciones. Saludos. Al González. |
|
|
|