On 11/11/15 6:45 AM, Alexander Kanavin wrote: > On 11/10/2015 06:39 PM, Mark Hatle wrote: > >>> This requires custom bitbake support I'm afraid, a specialist needs to >>> answer this. >>> >> >> Let me rephrase. Instead of calling out to qemu (or a real target) for a >> gobject and result. Can the result be cached (like we do with the >> config-site >> info?) This would allow me to run say a MIPS64 n64 gobject build, cache the >> results and use it on my octeon3 build (which can't run in QEMU.) > > The results in this case are .typelib files. They are raw dumps of a C > structure in memory - different compilers may produce different binary > representations of those. I wouldn't trust that they are the same and > that it's okay to copy them around like this. What makes you confident > that they are?
For the same architecture (i.e. MIPS64) and the same ABI (n64), the resulting data structures, packing and similar should all be standard. Only the generated instructions and execution order would/could change. So you would need a way to generate, cache, store the results by arch/abi combo in order to do this. The issue of course is that you would need to declare the arch and abi -- the tune files are the natural place to do this (we really are declaring it there ANYWAY), and the tune features in many cases may have already done this... Something to consider -- the alternative is the dual object (one generic [arch/abi], one optimized for the tune) that can be used to run on QEMU. Twice the compile time but should work fine. Also has anyone looked at the .typelib information and determined if any of it is available via direct inspection via readelf, dwarf interpretation or other method that does not require execution? Is there a definition of the .typelib information anywhere and some simple examples of how its generated by the runtime objects? (To pursue this, the way forward is to determine a way to generate the .typelib by reading the chosen binaries in some way -- and then running a 'ptest' like check that the generated and runtime versions result in the same data.) --Mark > > Alex > -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
