enlace dinámico con LLVM

Quiero ejecutar funciones en un módulo, este módulo tendrá dependencias resueltas en otros módulos. los módulos pueden cambiar (entorno de compilación dinámica) así que preferiría no vincular todas las dependencias en un solo módulo monolítico, es decir, si se puede evitarenlace dinámico con LLVM

Espero usar Linker::linkModules pero esto siempre es destructivo para la fuente módulo. Eso está bien para un módulo que depende de uno solo, ya que si eso cambió, no es gran cosa, pero ¿no es excesivo reconstruir y volver a vincular los módulos N-1 que no cambiaron solo por una sola que cambió?

Me pregunto si existe una versión no destructiva de linkModules que pueda funcionar para la ejecución de JIT.

Fuente

2012-06-04 lurscher

Prueba esto:

Linker::LinkModules(destinationModule, sourceModule, Linker::PreserveSource, &error);

Si pasa Linker::PreserveSource en lugar de Linker::DestroySource, puede seguir utilizando sourceModule después de la llamada.

Fuente

2014-01-16 17:56:01 jlstrecker

No creo que sea posible la forma en que usted describe el problema.

En su solución ideal, si los módulos A y B estaban vinculados, cambiando B sería inmediatamente observables en A?

Si este es el caso, no creo que esto sea posible. (Intente buscar en el contenido de A después de enlazar B. Los símbolos de B se han copiado en A)

Si simplemente desea perserve la información en B, es posible copiar B primero con llvm::CloneModule, pasando el resultado a Linker::linkModules .

Fuente

2012-06-12 18:25:20 srossross

como en bibliotecas compartidas normales, si 'B'cambia,' A' todavía necesitaría volver a vincularse con el nuevo B. Mi punto es: si A está vinculado contra 'B0',' B1' ... 'BN 'y uno de ellos cambia, solo tendré que volver a vincular las referencias a esa, ya que el resto no cambió. El linkModules actual funciona como un enlazador estático (copiando todo en el módulo de destino) – lurscher

El kernel de Linux, con sus módulos, permite algo como esto (descargar un módulo, volver a cargar una nueva versión). Pero allí el proceso está bajo el control del kernel, y existen enclavamientos para garantizar que el código no se esté utilizando. – vonbrand

Hemos hecho algo similar en el entorno de compilación dinámica dentro de nuestro producto Fabric Engine (http://fabricengine.com/). LLVM no está actualmente muy bien adaptado a este tipo de entorno "JIT" complejo, pero logramos hacerlo funcionar enlazando un nivel adicional de direccionamiento indirecto (es decir, un puntero doble) y luego subclasando llvm :: MemoryManager para sobrecargar llvm: : MemoryManager :: getPointerToNamedFunction para resolver símbolos globalmente entre módulos. Al usar un puntero doble, puede cambiar un módulo sin cambiar ninguno. Tienes que ser un poco cuidadoso, pero no es tan malo.

Fuente

2014-02-17 20:45:55

Respuesta

Cuestiones relacionadas