__cxa_thread_call_dtors(3): fix dtor pointer validity check

[kib]

Summary

When checking for the destructor pointer belonging to some still
loaded dso, do not limit the possible dso to the one instantiated the
destructor. For instance, dso could set up the dtr pointer to a function
from libcxx.

PR:     278701

[dim]

Does the cxa_thread_dtor::dso field serve any function after this change? I couldn't see any other references to it.

[kib]

In D45074#1027845, @dim wrote:

Does the cxa_thread_dtor::dso field serve any function after this change? I couldn't see any other references to it.

It is unused indeed. I looked at the glibc code, they use it to deref the dso after dtr call, but then it would have the same issue. Musl seems to not have the cxa_* stuff at all.

I can remove the member, but prefer to keep it for now (not a rational decision).

[vd]

I confirm that this change silences the message from https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278701 and also that the destructor is actually being called.

Further as mentioned above by @dim the dso member is no longer used and can be removed together with the arguments of some functions, see the attached patch.{F82874513}

Thank you!

[dim]

In D45074#1027873, @kib wrote:

In D45074#1027845, @dim wrote:

Does the cxa_thread_dtor::dso field serve any function after this change? I couldn't see any other references to it.

It is unused indeed. I looked at the glibc code, they use it to deref the dso after dtr call, but then it would have the same issue. Musl seems to not have the cxa_* stuff at all.

Yeah musl doesn't implement unloading DSOs altogether, avoiding a huge can of worms! That's apparently POSIX-compliant...

I can remove the member, but prefer to keep it for now (not a rational decision).

Oh it's fine, it might be handy for other things later, possibly in debug output or such.