[OE-core] [PATCH 00/29] Add gobject introspection support to oe-core

[Mark Hatle]

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
>