{"id":305,"date":"2026-01-15T14:18:58","date_gmt":"2026-01-15T14:18:58","guid":{"rendered":"https:\/\/haco.club\/?p=305"},"modified":"2026-01-15T14:18:58","modified_gmt":"2026-01-15T14:18:58","slug":"executable-exports-symbols","status":"publish","type":"post","link":"https:\/\/haco.club\/?p=305","title":{"rendered":"Executable Exports Symbols"},"content":{"rendered":"\n

There are actually several critical scenarios<\/strong> where an executable must<\/strong> export symbols.<\/p>\n\n\n\n

The confusion usually lies in the direction of the linking. You are right that Executable A<\/strong> rarely links dynamically to Executable B<\/strong> to call functions inside B.<\/p>\n\n\n\n

However, the reverse happens frequently: Dynamic Libraries (Plugins)<\/strong> loaded by Executable A<\/strong> often need to call functions inside Executable A<\/strong>.<\/p>\n\n\n\n

Here are the specific reasons why an executable needs to keep exported symbols:<\/p>\n\n\n\n

1. The “Host-Plugin” Architecture (Most Common)<\/h3>\n\n\n\n

This is the primary reason. If your executable supports plugins (DLLs on Windows, .so<\/code> files on Linux) that are loaded at runtime, those plugins often need to use functionality provided by the main executable.<\/p>\n\n\n\n

    \n
  • How it works:<\/strong> The main executable loads the plugin (using dlopen<\/code> or LoadLibrary<\/code>).<\/li>\n\n\n\n
  • The Problem:<\/strong> The plugin code needs to call GetMainAppVersion()<\/code> or LogMessage()<\/code>, which are defined inside the .exe<\/code>.<\/li>\n\n\n\n
  • The Solution:<\/strong> The executable exports<\/strong> those symbols. When the dynamic linker loads the plugin, it resolves the plugin’s undefined references by looking at the executable’s exported symbol table (the Global Symbol Table).<\/li>\n\n\n\n
  • Linux Flag:<\/strong> On Linux (GCC\/Clang), you often use -rdynamic<\/code> or --export-dynamic<\/code> to force the linker to add internal symbols to the dynamic symbol table so plugins can see them.<\/li>\n<\/ul>\n\n\n\n

    2. Runtime Introspection (dlopen(NULL)<\/code>)<\/h3>\n\n\n\n

    Sometimes an application needs to look up a function within itself<\/strong> by string name at runtime.<\/p>\n\n\n\n

      \n
    • Scenario:<\/strong> You have a configuration file that says action = \"do_save\"<\/code>. The code reads this string and wants to find the function void do_save()<\/code> in memory to execute it.<\/li>\n\n\n\n
    • Mechanism:<\/strong> The code calls dlsym(dlopen(NULL, ...), \"do_save\")<\/code>.<\/li>\n\n\n\n
    • Requirement:<\/strong> do_save<\/code> must be in the dynamic symbol table (exported) for dlsym<\/code> to find it. If you strip the executable or hide symbols, this look-up fails.<\/li>\n<\/ul>\n\n\n\n

      3. Stack Traces and Crash Reporting<\/h3>\n\n\n\n

      If you want your application to print a readable stack trace (backtrace) when it crashes without<\/strong> relying on external debug files (like .pdb<\/code> or separate debug info), the executable needs symbols.<\/p>\n\n\n\n

      While “debug symbols” (DWARF) are usually used for this, many backtrace libraries (like execinfo.h<\/code> on Linux) can fall back to using exported dynamic symbols<\/strong> (.dynsym<\/code>) to give you at least the function names, even if line numbers are missing.<\/p>\n\n\n\n

      4. Sanitizers and Profilers (ASan, Valgrind)<\/h3>\n\n\n\n

      Tools like Google’s AddressSanitizer (ASan) or Valgrind often intercept function calls (like malloc<\/code>) or need to symbolize addresses at runtime.
      If an executable is fully stripped of exports, these tools may output addresses like 0x4005d3<\/code> instead of main<\/code> or process_request<\/code>, making the output much harder to read or causing the tool to fail to intercept specific calls.<\/p>\n\n\n\n

      5. Windows Specifics (Hybrid EXE\/DLL)<\/h3>\n\n\n\n

      On Windows, it is technically possible (though rare) to treat an .exe<\/code> exactly like a .dll<\/code>.<\/p>\n\n\n\n

        \n
      • You can run LoadLibrary(\"my_app.exe\")<\/code> from another process.<\/li>\n\n\n\n
      • If my_app.exe<\/code> exports functions, the other process can call GetProcAddress<\/code> and use them.<\/li>\n\n\n\n
      • Why do this?<\/em> It is sometimes used in resource sharing or niche inter-process communication setups, though standard IPC is preferred.<\/li>\n<\/ul>\n\n\n\n

        Summary: Do you need them?<\/h3>\n\n\n\n
          \n
        1. If you are building a standard, standalone CLI tool:<\/strong>\n
            \n
          • No.<\/strong> You generally do not need exported symbols. You can strip them to save space and obfuscate the code.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
          • If you are building a program that loads plugins:<\/strong>\n
              \n
            • Yes.<\/strong> You likely need to export the API that the plugins will use.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
            • If you use dlsym<\/code> \/ Reflection:<\/strong>\n
                \n
              • Yes.<\/strong> You need exports to find functions by name.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n

                Technical Note:<\/strong> There is a difference between Debug Symbols<\/strong> (used by GDB, not loaded into memory, safe to strip) and Dynamic Symbols<\/strong> (used by the OS loader, loaded into memory). Your question refers to Dynamic Symbols. Standard executables usually have a very small dynamic symbol table (just libc dependencies) unless configured otherwise.<\/p>\n\n\n\n

                \n\n\n\n
                \n\n\n\n
                \n\n\n\n

                The Dynamic Symbol Table (specifically .dynsym<\/code> in ELF files on Linux\/Unix) is essentially a shopping list for the Dynamic Linker<\/strong>.<\/p>\n\n\n\n

                It contains two main categories of items: Things I need (Imports)<\/strong> and Things I have (Exports)<\/strong>.<\/p>\n\n\n\n

                Here is the breakdown of exactly what is contained inside.<\/p>\n\n\n\n

                1. Imports (Undefined Symbols)<\/h3>\n\n\n\n

                These are symbols that your executable uses but does not define itself. They represent external dependencies.<\/p>\n\n\n\n

                  \n
                • What they look like:<\/strong> In the symbol table, they are usually marked as UND<\/strong> (Undefined).<\/li>\n\n\n\n
                • Purpose:<\/strong> They tell the OS loader: “Before you run me, please search the loaded shared libraries (like libc.so<\/code>, libm.so<\/code>) to find the address of these functions.”<\/em><\/li>\n\n\n\n
                • Examples:<\/strong>\n
                    \n
                  • Standard C library functions: printf<\/code>, malloc<\/code>, free<\/code>.<\/li>\n\n\n\n
                  • External variables: stdout<\/code>, stderr<\/code>.<\/li>\n\n\n\n
                  • Third-party library functions: SSL_connect<\/code> (if using OpenSSL).<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n

                    2. Exports (Global Defined Symbols)<\/h3>\n\n\n\n

                    These are symbols that your executable defines and has decided to expose to the outside world.<\/p>\n\n\n\n

                      \n
                    • What they look like:<\/strong> They have a specific memory address or offset associated with them.<\/li>\n\n\n\n
                    • Purpose:<\/strong> They tell the OS loader: “If any other object (like a plugin or a library I loaded) asks for this name, point them to this address inside me.”<\/em><\/li>\n\n\n\n
                    • Caveat for Executables:<\/strong> By default, standard executables usually contain very few<\/strong> exports (often just _start<\/code> or __bss_start<\/code>). As discussed previously, you usually have to force the linker (via -rdynamic<\/code> or __declspec(dllexport)<\/code>) to move your global functions from the “debug\/static symbol table” into this “dynamic symbol table.”<\/li>\n<\/ul>\n\n\n\n

                      3. Weak Symbols<\/h3>\n\n\n\n

                      These are a special sub-category.<\/p>\n\n\n\n

                        \n
                      • Weak Imports:<\/strong> “I need this symbol, but if you can’t find it, don’t crash the program; just set the address to NULL.” (Used for optional features).<\/li>\n\n\n\n
                      • Weak Exports:<\/strong> “I provide this function, but if a loaded library provides a function with the same name, use theirs instead of mine.” (Used for overridable implementations).<\/li>\n<\/ul>\n\n\n\n
                        \n\n\n\n

                        Visualization (How to see them)<\/h3>\n\n\n\n

                        You can see exactly what is in your executable’s dynamic symbol table using the nm<\/code> command with the -D<\/code> (dynamic) flag.<\/p>\n\n\n\n

                        Command:<\/strong><\/p>\n\n\n\n

                        nm -D my_executable<\/code><\/pre>\n\n\n\n
                        Output Example:<\/strong><\/p>\n\n\n\n
                                         U free               <-- IMPORT (Undefined): Needs 'free' from libc\n0000000000404028 B __bss_start        <-- EXPORT (Global Data): Start of BSS section\n                 U malloc             <-- IMPORT (Undefined): Needs 'malloc'\n0000000000401126 T my_plugin_api      <-- EXPORT (Text\/Code): A function I expose\n                 U printf             <-- IMPORT (Undefined): Needs 'printf'<\/code><\/pre>\n\n\n\n
                        Important Distinction: .symtab<\/code> vs .dynsym<\/code><\/h3>\n\n\n\n
                        To fully understand the “necessity” question, you must distinguish between the two symbol tables inside a binary:<\/p>\n\n\n\n
                          \n
                        1. The Dynamic Symbol Table (.dynsym<\/code>)<\/strong>:\n
                            \n
                          • Contents:<\/strong> Only Imports and Exports.<\/li>\n\n\n\n
                          • Size:<\/strong> Small.<\/li>\n\n\n\n
                          • Necessity:<\/strong> Required<\/strong> for the program to run (the loader needs it to resolve printf<\/code>).<\/li>\n\n\n\n
                          • Strippable?<\/strong> No (mostly). You cannot strip this, or the program breaks.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                          • The “Full” Symbol Table (.symtab<\/code>)<\/strong>:\n
                              \n
                            • Contents:<\/strong> Everything above PLUS<\/strong> local static functions, internal variables, source file names, and compilation units.<\/li>\n\n\n\n
                            • Size:<\/strong> Large.<\/li>\n\n\n\n
                            • Necessity:<\/strong> Not required for running. Only used for debugging (GDB) and static linking.<\/li>\n\n\n\n
                            • Strippable?<\/strong> Yes. When you run the strip<\/code> command, this<\/em> is what gets deleted.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n
                              Summary<\/h3>\n\n\n\n
                              So, to answer your specific phrasing:<\/p>\n\n\n\n
                                \n
                              • Does it contain External Library Symbols?<\/strong> Yes (as “Undefined” placeholders).<\/li>\n\n\n\n
                              • Does it contain Exported Global Symbols?<\/strong> Yes (as “Defined” addresses), but only if<\/em> the executable was configured to export them.<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"
                                There are actually several critical scenarios where an executable must […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[42],"tags":[30,52],"class_list":["post-305","post","type-post","status-publish","format-standard","hentry","category-knowledge-base","tag-binary","tag-symbols"],"_links":{"self":[{"href":"https:\/\/haco.club\/index.php?rest_route=\/wp\/v2\/posts\/305","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/haco.club\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/haco.club\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/haco.club\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/haco.club\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=305"}],"version-history":[{"count":1,"href":"https:\/\/haco.club\/index.php?rest_route=\/wp\/v2\/posts\/305\/revisions"}],"predecessor-version":[{"id":306,"href":"https:\/\/haco.club\/index.php?rest_route=\/wp\/v2\/posts\/305\/revisions\/306"}],"wp:attachment":[{"href":"https:\/\/haco.club\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=305"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/haco.club\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=305"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/haco.club\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=305"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}