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
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
