Re: llvm & RTTI over shared libraries

From: Mark Millard <>
Date: Wed, 27 Apr 2022 00:48:00 UTC
	• Joerg Sonnenberger <> wrote on
	• Date: Tue, 26 Apr 2022 23:47:23 UTC :

> Am Mon, Apr 25, 2022 at 03:39:48PM -0700 schrieb Mark Millard:
> > Basically I avoid inline definitions of:
> > 
> > virtual ~type_base();
> > virtual ~type_int();
> > virtual ~type_string();
> You only need to ensure that the class has one non-pure non-inline
> function.

I'm confused at what you are claiming that I did wrong or
described incorrectly for the example at hand. Those are 3
separate classes each with one virtual method that is not
in line (and that I showed the definitions for later in
the message). No other such functions were involved explicitly
in those 3 classes.

The gcc class type_info in /usr/local/lib/gcc11/include/c++/typeinfo
describes this implementation detail for type_info itself, as its
example, via:

  class type_info
    /** Destructor first. Being the first non-inline virtual function, this
     *  controls in which translation unit the vtable is emitted. The
     *  compiler makes use of that information to know where to emit
     *  the runtime-mandated type_info structures in the new-abi.  */
    virtual ~type_info();
. . .

> That's the key function and determines the translation unit
> (and by extension the DSO) where the virtual table and the typeinfo is
> placed.

I'm a again confused about where the above disagrees with
what I wrote (in text that you did not quote).

> If there is no such function, both will be defined as weak
> mergable symbol and that will not result in a unique address when using

I was certainly less detailed about how multiple definitions
are handled. Was that your point?

Let me know if I've missed some import point --or made some
stupid screwup in what I'd written.

Mark Millard
marklmi at