On 11/16/15 3:52 AM, Alexander Kanavin wrote: > On 11/13/2015 06:31 PM, Mark Hatle wrote: > >> The compiler today support many more instructions for a given architecture >> family then QEMU models for that same architecture. >> >> IA32 -- some of the current and even some former generate i7 instructions >> fall >> under this problem. If you host system does not have the same instruction >> set, >> QEMU doesn't know how to emulate everything. >> >> MIPS64 (Such as the Octeon III) is a good example. >> >> PowerPC has many variants as well that QEMU does not support. >> >> It would be wonderful if there was a tie together of what gcc/as and qemu >> supported -- at least from an application perspective, but that simply >> doesn't >> happen in the real world. > > How about approaching this from the other side then? Machines can be > defined so that if gobject introspection distro feature is enabled, then > the standard qemu-supported compiler settings are used (same as > qemumips64 for instance). If not, then people can tweak the compiler to > their heart's content.
Problem is that gobject can't be limited by a 'machine'. Since any machine needs to theoretically have access to gobject built components. (ignoring that machines should never specify distro features...) I think a small group of folks that are interested in this work and who understand facets of it should get together and try to identify the problem and come up with an alternative solution. I have a lot of experience with pulling out internal structure size, packing, order, etc from generated binaries via objdump, readelf and other mechanisms -- but I have no experience using gobject itself. So if we could get together to identify how a gobject binary is generated -- how the introspection happens internally -- and the output of the introspection tool. It's very likely that I or others can come up with an approach to do the introspection that doesn't require QEMU. (It may require the gobject binary generation having additional information placed in it -- or an introspection to occur at the time of compilation and saved away in a cache...) but the point is, we need to figure out a general solution to this that doesn't require QEMU for "most things". (BTW just to reiterate. I COMPLETELY believe that we need to add gobject support to oe-core in the next year. And we need to try to help the gobject community better support cross compilation as well, if they are receptive -- without dramatically altering there existing work.) --Mark > > Alex > -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
