glib/gobject/gobject_probes.d
Emmanuele Bassi 3c53fb8790 Move the GLib type system into libglib
The type system should have never been relegated to libgobject: it's a low
level API to register types at run time.

Having GType inside libglib allows us to use the type system information
everywhere:

- generic but type safe storage data types
- explicit memory management semantics for all data types
- enumeration types for all flags

Having the type system inside libglib also allows us to create new and
better fundamental types in the future, like sum types, option types,
tuples, and generic types.

Moved:

- gatomicarray
- gboxed
- genums
- gtype
- gtypeplugin
- gvalue

The move is mostly Git surgery, but given the amount of internal API
surface, it results in a single commit to avoid breaking bisectability.

We need to maintain `gobject/gvaluecollector.h` as a publicly installed
header but, to avoid issues in case of excessive inclusions, we make it
conflict with `glib/gvaluecollector.h`.

See: #2370

See: https://discourse.gnome.org/t/straw-man-moving-the-gtype-api-down-to-libglib-2-0/11169
2025-01-03 22:56:56 +00:00

13 lines
608 B
D

provider gobject {
probe object__new(void*, unsigned long);
probe object__ref(void*, unsigned long, unsigned int);
probe object__unref(void*, unsigned long, unsigned int);
probe object__dispose(void*, unsigned long, unsigned int);
probe object__dispose__end(void*, unsigned long, unsigned int);
probe object__finalize(void*, unsigned long);
probe object__finalize__end(void*, unsigned long);
probe signal__new(unsigned int, char *, unsigned long);
probe signal__emit(unsigned int, unsigned int, void *, unsigned long);
probe signal__emit__end(unsigned int, unsigned int, void *, unsigned long);
};