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

libdeps graph linter: Initializer Linting



    • New Feature
    • Status: Backlog
    • Major - P3
    • Resolution: Unresolved
    • None
    • None
    • None
    • None


      from the document:

      While all of the above transformations are appealing, it was noted that there was one that we simply can’t achieve safely: removing edges.


      We frequently have nodes in the graph that exist only for their side effects, where they are linked so that static initializers will run and have side effects (like command registration). If we ever want to be able to remove edges, we need to be able to validate that removing those edges does not break the initializer graph. Is such a thing possible? Can it be done statically? Must we run code?


      Here is a somewhat disorganized list of potential solutions to part of the problem:


      • Can we ban C++ static initializers that reach outside of the current library and require the use of mongo initializers? That would greatly reduce the scope of the problem, but raises another of identifying all such initializers. Many C++ static initializers are simply innocent strings. How can we find the ones that have spooky action at a distance? Can the linker help somehow, maybe with a linker plugin? If a C++ initializer implementation contains references to unresolved symbols that are provided by one its library dependencies?
      • We could operate under the assumption that the initializer graph is currently correct. Then we could write a program which dlopen’d each program and shared library and invoked the mongo initializer entry point in a special mode which dumped all the executed initializers and their DAG. If removing an edge caused any change in the initializer graph realized by any target, we could flag the libdep removal as invalid.

      Other ideas are most welcome.


        Issue Links



              backlog-server-devplatform Backlog - Server Development Platform Team (SDP)
              daniel.moody@mongodb.com Daniel Moody
              0 Vote for this issue
              1 Start watching this issue