Thanks for reporting. Can you please provide a reproducing example? E.g. the binaries before/after the change or the abi.xml files extracted with abidw from before/after? Ideal would be some source code that demonstrates the missing analysis. (you got hold off the relevant object files, maybe?)

In particular, it would be interesting to see how "gpointer deprecated" participates in the ABI surface of the library.

Reproducer:

https://gitlab.gnome.org/GNOME/glib/

meson setup build && ninja -C build
DESTDIR=/tmp/old ninja -C build install

Modify a base class:

diff --git a/gobject/gtypemodule.h b/gobject/gtypemodule.h
index 5c4025063..f15f18a32 100644
--- a/gobject/gtypemodule.h
+++ b/gobject/gtypemodule.h
@@ -80,7 +80,6 @@ struct _GTypeModuleClass
   void (*reserved1) (void);
   void (*reserved2) (void);
   void (*reserved3) (void);
-  void (*reserved4) (void);
 };
 

ninja -C build
DESTDIR=/tmp/new ninja -C build install

abidiff --headers-dir1 /tmp/old/usr/include/glib-2.0/gobject --headers-dir2 /tmp/new/usr/include/glib-2.0/gobject/  --fail-no-debug-info --no-added-syms                 /tmp/old/usr/lib64/libgobject-2.0.so.0.6900.0 /tmp/new/usr/lib64/libgobject-2.0.so.0.6900.0

The starting point is that GTypeModuleClass isn't being used explicitely by functions. Yet it is the base class / vfunc / private of objects and should have ABI stability.

I am not familiar with glib and/or meson. Does this build produce debug symbols in the final binary?

Can you try whether this is reported in the harmless mode (--harmless)?

It would be helpful if you would upload binaries (before/after the change) to this tracking bug.

> Can you try whether this is reported in the harmless mode (--harmless)?

Yes, no change reported either.

> It would be helpful if you would upload binaries (before/after the change) to this tracking bug.

ok

Created attachment 13363 [details]
Old gobject.so

Created attachment 13364 [details]
New gobject.so

Thanks for that.

I can see that:
 - _GTypeModuleClass increases in size from old->new in DWARF
 - old and new have debug information sufficient for ABI analysis
 - _GTypeModuleClass is not attached directly or indirectly as a type to any ELF symbol

Can you please tell me which symbol you would expect to become incompatible based on a change to this class? How does it relate to any of the exported symbols?

(In reply to Matthias Maennich from comment #7)
> Thanks for that.
> 
> I can see that:
>  - _GTypeModuleClass increases in size from old->new in DWARF
>  - old and new have debug information sufficient for ABI analysis
>  - _GTypeModuleClass is not attached directly or indirectly as a type to any
> ELF symbol
> 
> Can you please tell me which symbol you would expect to become incompatible
> based on a change to this class? How does it relate to any of the exported
> symbols?

FooClass/vtable (and other object-oriented structures) are often passed around as void * (or parent types) on the public functions etc. However, the implementation then cast the void/parent pointer to some concrete type, and expect the structure to keep the same layout.

So any change in those OO structures is an ABI break, it would be nice to catch them.

Anything passed to the API via opaque pointers is essentially hidden from ABI analysis as no type information (other than void*) is attached to it. From an ABI point of view the ABI of the symbol that passes void* is unchanged. Though further down this of course can become incompatible.

There are cases that you intentionally want to pass void* to be ABI compatible even though the type changes. E.g. if your library has such an interface:

void* get_handle(){
  // allocates the resources and returns just a handle to it.
  ...
  return (void*) some_object;
}

void do_something(void* handle) {
  // uses the handle as a reference
}

The ABI is stable even though the type could have changed. The client code might not even know the concrete type and is also not supposed to cast to it.

So, as much as I would also like to sometimes inspect underlying types of void*, flagging changes to those types is probably wrong. If you want this type to be stable, you need to let it participate as a type in the interface.

One way of achieving this is to define a symbol just for the sake of ABI analysis:

void (struct _GTypeModuleClass obj) { }

This will get picked up by libabigail and the type will participate in the analysis then.

Isn't the a way to annotate a type in a header for abi check?

That would be useful in other cases, like shared header structures for protocols and shared structures (common in virtualized hardware for instance)

(In reply to Matthias Maennich from comment #9)
> [..] 
> So, as much as I would also like to sometimes inspect underlying types of
> void*, flagging changes to those types is probably wrong. If you want this
> type to be stable, you need to let it participate as a type in the interface.

This bug is about structures that are exposed in the public header. So they may be taken as argument, or returned, by void* or parent* pointers, but it would be nice to annotate the actual type

> One way of achieving this is to define a symbol just for the sake of ABI
> analysis:
> 
> void (struct _GTypeModuleClass obj) { }
> 
> This will get picked up by libabigail and the type will participate in the
> analysis then.

Ok, but I am looking for a more friendly way to express that *all* my types in my headers must be taken into account without having to define such extra symbols. Imho it should be an option to the tool somehow.