Sometimes the dladdr function fails to find some symbol names in the v-table.

Output of vtable-dumper /usr/lib64/libQt5Gui.so.5.4.2:

Vtable for QImageTextureGlyphCache
_ZTV23QImageTextureGlyphCache: 10 entries
0     (int (*)(...)) 0
8     (int (*)(...)) (& _ZTI23QImageTextureGlyphCache)
16    (int (*)(...)) QImageTextureGlyphCache::~QImageTextureGlyphCache()
24    (int (*)(...)) QImageTextureGlyphCache::~QImageTextureGlyphCache()
32    (int (*)(...)) QImageTextureGlyphCache::createTextureData(int, int)
40    (int (*)(...)) QImageTextureGlyphCache::resizeTextureData(int, int)
48    (int (*)(...)) 0x32d210
56    (int (*)(...)) QImageTextureGlyphCache::fillTexture(QTextureGlyphCache::Coord const&, unsigned int, QFixed)
64    (int (*)(...)) 0x32d220
72    (int (*)(...)) 0x32d230

The tool can't find symbol names for 0x32d210, 0x32d220 and 0x32d230.

The g++ -fdump-class-hierarchy ./qtextureglyphcache_p.h returns for this class:

Vtable for QImageTextureGlyphCache
QImageTextureGlyphCache::_ZTV23QImageTextureGlyphCache: 10u entries
0     (int (*)(...))0
8     (int (*)(...))(& _ZTI23QImageTextureGlyphCache)
16    (int (*)(...))QImageTextureGlyphCache::~QImageTextureGlyphCache
24    (int (*)(...))QImageTextureGlyphCache::~QImageTextureGlyphCache
32    (int (*)(...))QImageTextureGlyphCache::createTextureData
40    (int (*)(...))QImageTextureGlyphCache::resizeTextureData
48    (int (*)(...))QTextureGlyphCache::glyphPadding
56    (int (*)(...))QImageTextureGlyphCache::fillTexture
64    (int (*)(...))QTextureGlyphCache::maxTextureWidth
72    (int (*)(...))QTextureGlyphCache::maxTextureHeight

The QTextureGlyphCache::* inline virtual methods names are missed in the vtable-dumper output.

You have Windows instructions for ABI Compliance Checker but not for your other products which ABICC depends on like ABI Dumper and Vtable Dumper.

You currently demangle the name/hashcode but it would also be useful to see the structure of type_info itself. Basically dump the -1 entry before the vtable (which is the type_info pointer) as well as the struct that is pointed to by that (type_info *) entry.
More info in http://refspecs.linuxbase.org/cxxabi-1.83.html#rtti chapter 2.9.5 RTTI Layout

dump-vtable.c:315:46: warning: flag '0' results in undefined behavior with 'p' conversion specifier [-Wformat]

 printf("(int (*)(...)) -%016p\n", (void*) -(ptrdiff_t)vfuncp);

dump-vtable.c:319:45: warning: flag '0' results in undefined behavior with 'p' conversion specifier [-Wformat]

  printf("(int (*)(...)) %016p\n", vfuncp);

vtable-dumper is explicitly linking to -lstdc++ used to provide __cxa_demangle(). However, libstdc++ is only valid for gcc (and clang with gcc libstdc++). The other compilers provide __cxa_demangle() in other libraries. For example, clang in GNU-free environment uses -lc++ (well, the needed symbol is actually often provided by -lc++abi or -lcxxrt sub-library), in which case -lstdc++ is either going to be wrong (i.e. force dependency on wrong C++ library on system using purely clang suite) or fail (when there is no gcc).

To be honest, I really don't see a point in building vtable-dumper as C if it requires the C++ library anyway. Therefore, the simplest solution to the problem would be to build it using a C++ compiler which in turn will use the correct C++ library for the ecosystem used (and also guarantee correct ABI for __cxa_demangle() calls — it would also be more correct to #include <cxxabi.h> instead of redeclaring the function).

I want to evaluate the ABI Compliance Checker on Windows but it's number of dependencies is just ridiculous and you don't even provide a script to automate this.

Cross compile sample library with arm toolchain:

$ arm-poky-linux-gnueabi-gcc -march=armv7ve -marm -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=/opt/poky/1.8.2/sysroots/cortexa7hf-neon-poky-linux-gnueabi -Wl,--version-script version -shared libsample.c -o libsample.so -g -Og -fPIC -DPIC

Use vtable-dumper on library for arm:

$ vtable-dumper libsample.so 
Failed to dlopen libsample.so
libsample.so: cannot open shared object file: No such file or directory

$ vtable-dumper ./libsample.so 
Failed to dlopen ./libsample.so
./libsample.so: wrong ELF class: ELFCLASS32

I have just gotten this accepted into Fedora but there's a couple of things that would be nice:

1. Makefile support for DESTDIR, since for packaging packages are built and installed as a normal user.
2. Makefile support for compiler flags (CFLAGS/CXXFLAGS/LDFLAGS). I worked around this using a sed replace of -Wall with %{optflags}.