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

[Alexander Kanavin <alexander.kanavin@linux.intel.com>]

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.

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.

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 :)

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.

Alex