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

[Mark Hatle]

On 11/17/15 8:06 AM, Alexander Kanavin wrote:
> On 11/16/2015 06:12 PM, Mark Hatle wrote:
> 
>> 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".
> 
> I know GObject fairly well, since I've done a medium-size project with 
> it (https://01.org/gsso/) and I think the above is totally unrealistic. 
> Below is an explanation why.
> 
> The idea of GObject is to make object oriented programming semantics 
> (classes, inheritance, methods, properties and signals) available to C 
> programmers. This is achieved by implementing a dynamic type system 
> called GType. It serves as a register of available types, to which new 
> types can be added, and information about existing types can be queried.
> 
> This type register is constructed entirely at runtime. When a 
> gobject-based library is loaded into memory, it adds the types that are 
> defined in the library (for example, classes and interfaces) to the 
> register using GType's API.

This is the key, the types and internal data structures are not dynamically
changing.  They are defined within the library.  (The object definitions may be
generated and exposed at runtime, but once a library is built -- they do not
change.)

> There are no tools that can extract the type information at source code 
> level, or any preprocessor for the special type syntax (like there is 
> for example a preprocessor called 'moc' in Qt). In the source code the 
> types are defined entirely using C syntax: a really awkward combination 
> of macros and function definitions that the macros refer to. The code 
> goes straight to the C compiler which of course knows nothing about the 
> types. So writing such a tool would basically amount to writing a 
> special-purpose C interpreter: not feasible.

I would need to see the code to understand this.  -IF- the macros and
definitions are done in a standard way, it is very much possible to interpret
the results of the macros via the intermediate objects.  But I need to see an
example of the code.

> When some library's types need to be introspected, a small binary is 
> compiled and linked with the library by the introspection build system, 
> and then executed. This binary iterates over available types, and asks 
> GType to describe them. These descriptions are then written in the XML 
> format to the .gir file. We cannot fetch this information directly from 
> internal structures of GType, because these structures don't exist on 
> disk; they're only created at runtime through executing type definition 
> functions. So again, you'd need some kind of bytecode interpreter to 
> extract this information from executable objects, which would look a lot 
> like QEMU :)

Another place where looking at the code may prove otherwise.  I need to see how
this is done to be able to comment.

> So the bottom line, to generate introspection info, you have to run the 
> code of the library that you introspect, either with QEMU, or on target 
> hardware, and I don't see a way to avoid this, short of complete rewrite 
> of the entire glib ecosystem. If someone wants to have this feature, but 
> doesn't have a working QEMU, they should get their act together and fix it.

Can you put together a small piece of test code with instructions on how to
compiler it, generate the '.gir' file and anything else?  I can take a look at
this and see if there is a way to inspect the intermediate objects for the type
information we need.

--Mark