Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-55737

Evaluate feasibility and impact of removing -rdynamic when using libunwind



    • Type: Task
    • Status: Blocked
    • Priority: Major - P3
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Build
    • Labels:
    • Backwards Compatibility:
      Fully Compatible


      We have for a long time linked all our binaries with the -rdynamic flag. This flag is unnecessary but harmless for shared library builds, and work to apply it only for program builds will be put in place under SERVER-49322.

      However, the original intention of adding the -rdynamic flag was to ensure that all symbols were included in the dynamic symbol table so that backtrace_symbols would work. When using libunwind we are no longer required to do so in order to get correct backtraces.

      The only remaining cases for which we would still need symbols to be exported from the program are those where we intend to look up the symbol via the dl APIs like dlsym or dladdr. This does in fact happen in our codebase, in two places:

      • In the machinery to handle fallback when libunwind fails to symbolize. We have a unit test for this situation and it does fail when built without -rdynamic.
      • The wiredtiger subsystem allows function names to be provided in its configuration which it then searches for with dlsym. If we were to build without -rdynamic, we would need to find a way to continue to ensure that those symbols were dynamic.

      We can investigate what it would take to allow explicit export of those few specific functions that must be present in the dynamic symbol table. Both ld.gold and ld.lld offer an --export-dynamic-symbol flag which can be used to export symbols on a per-instance basis.




            backlog-server-devplatform Backlog - Server Development Platform Team (SDP)
            acm Andrew Morrow
            0 Vote for this issue
            2 Start watching this issue