Re: llvm & RTTI over shared libraries

On 2022-Apr-26, at 17:48, Mark Millard <marklmi@yahoo.com> wrote:
> 
> 	• Joerg Sonnenberger <joerg_at_bec.de> 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
>  {
>  public:
>    /** 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();
> . . .

May be the intent is tied to what happens with
a one line change, using

    struct type_base
    {
        ~type_base() = 0;
    };

but still having the required definition:

interface::type_base::~type_base()     {}

(implicitly referenced so required in order
to link). This makes type_base abstract (not
something to potentially directly create).

The original example did not have that property,
so I did not make my nearly minimal change that
way. But using the '= 0' as above does produce
a working program:

# ./test-core 
t is type_int
t is type_string
done.

>> 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
>> RTLD_LOCAL.
> 
> 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 yahoo.com