Where is __dso_handle defined?

Question

I have an unresolved symbol error when trying to compile my program which complains that it cannot find __dso_handle. Which library is this function usually defined in?

Does the following result from nm on libstdc++.so.6 mean it contains that?

I tried to link against it but the error still occurs.

nm libstdc++.so.6 | grep dso
00000000002fc480 d __dso_handle

Stokeontrent

Answer 1

__dso_handle is a "guard" that is used to identify dynamic shared objects during global destruction.

Thom Chiovoloni wrote a concise description of __dso_handle while debugging issues related to it:

__dso_handle is a magic symbol that has a different value in every .so (it's a hidden symbol provided by the loader). It's used ... to let the runtime ("the runtime" = libc + loader + ...) know which shared library the thread local dtor applies to, which allows the runtime to avoid some cases where it would call a function pointer coming from an unloaded module.

Realistically, you should stop reading here. If you're trying to defeat object identification by messing with __dso_handle, something is likely very wrong.

However, since you asked where it is defined: the answer is complex. To surface the location of its definition (for GCC), use iostream in a C++ file, and, after that, do extern int __dso_handle;. That should surface the location of the declaration due to a type conflict (see this forum thread for a source).

Sometimes, it is defined manually.

Sometimes, it is defined/supplied by the "runtime" installed by the compiler (in practice, the CRT is usually just a bunch of binary header/entry-point-management code, and some exit guards/handlers). In GCC (not sure if other compilers support this; if so, it'll be in their sources):

• Main definition
• Testing __dso_handle replacement/tracker example 1
• Testing __dso_handle replacement/tracker example 2

Often, it is defined in the stdlib:

• Android
• BSD

Further reading:

• Subtle bugs caused by __dso_handle being unreachable in some compilers

Rollie

Answer 2

I ran into this problem. Here are the conditions which seem to reliably generate the trouble:

1. g++ linking without the C/C++ standard library: -nostdlib (typical small embedded scenario).
2. Defining a statically allocated standard library object; specific to my case is std::vector. Previously this was std::array statically allocated without any problems. Apparently not all std:: statically allocated objects will cause the problem.
3. Note that I am not using a shared library of any type.
4. GCC/ARM cross compiler is in use.

If this is your use case then merely add the command line option to your compile/link command line: -fno-use-cxa-atexit

Here is a very good link to the __dso_handle usage as 'handle to dynamic shared object'.

There appears to be a typo in the page, but I have no idea who to contact to confirm:

After you have called the objects' constructor destructors GCC automatically calls the function ...

I think this should read "Once all destructors have been called GCC calls the function" ...

One way to confirm this would be to implement the __cxa_atexit function as mentioned and then single step the program and see where it gets called. I'll try that one of these days, but not right now.

Pussyfoot

Will this cause memory leaks, considering the other answer? – Downgrade

adding -fno-use-cxa-atexit made no change in error output for me. My error: undefined reference to `__dso_handle' I'm using -nostdlib in my g++ call – Basion

Answer 3

Adding to @natersoz's answer-

For me, using -Wabi-tag -D_GLIBCXX_USE_CXX11_ABI=0 alongside -fno-use-cxa-atexit helped compile an old lib. A telltale is if the C++ functions in the error message have std::__cxx11 in them, due to an ABI change.

Downgrade