title: Instrumenting a C library
body: <p>I have a binary library and a binary executable using that library, both written in C. I know the C API provided by the library, but neither the source of the library or the executable. I would like to understand how the executable uses the library (compare my previous question <a href="https://stackoverflow.com/questions/54847557/how-to-know-which-functions-of-a-library-get-called-by-a-program">How to know which functions of a library get called by a program</a>). </p>
  
  <p>The proposed solutions did not give satisfactory results. A possibility not mentioned seems to be to implement a wrapper library that imitates the known interface of the binary library I am interested in. My idea is to forward all of the calls to the wrapper to the binary library. This should allow me to log all the calls and passed parameters, in other words to instrument the library. </p>
  
  <p>I succeeded in implementing the wrapper library on Linux as a dynamic link library (*.so), together with my own sample application connecting to the wrapper. The wrapper, in turn, uses the original binary library. Both libraries are used with <code>dlopen</code> and <code>dlsym</code> to access the API. However, I am facing the following practical problem: I do not manage to link the original binary executable to my wrapper library. That is related to the fact that the executable expects the library under a certain name. However, if I name my rapper library that way, it conflicts with the original library. Surprisingly (to me) simply renaming the .so-file of that one and linking the wrapper library against it does not work (The result stops without error message when the wrapper library calls <code>dlopen</code> and I do not get more information from the debugger than that it seems to happen in an <code>malloc</code>).</p>
  
  <p>I tried a number of things like using symbolic links to move one of the libraries out of the search path of the run-time linker, to add paths to the <code>LD_LIBRARY_PATH</code> environment variable, different relative locations of the .so-files (and corresponding paths for <code>dlopen</code>), as well as different compiler options, so far without success. </p>
  
  <p>To summarize, I would like </p>
  
  <pre><code>(executable)_orig-&gt;(lib.so)-&gt;(lib.so)_orig
  </code></pre>
  
  <p>where <code>(executable)_orig</code> and <code>(lib.so)_orig</code> (both binaries that I cannot influence) are such that</p>
  
  <pre><code>(executable)_orig-&gt;(lib.so)_orig
  </code></pre>
  
  <p>works. I have the sources of <code>(lib.so)</code> and can modify it as I wish. Also, I can modify the Linux host system as I like. The task of <code>(lib.so)</code> is to tell me how <code>(executable)_orig</code> and <code>(lib.so)_orig</code> interact.</p>
  
  <p>I also have </p>
  
  <pre><code>(executable)-&gt;(wrapper.so)-&gt;(lib.so)_orig
  </code></pre>
  
  <p>working, which seems to indicate that the issue is related to the naming and loading conventions for the libraries.</p>
  
  <p>This is a separate new question because it deals with the specific practical issue sketched above. Beyond that, some background info on why renaming the file corresponding to <code>(lib.so)_orig</code> to circumvent the issue may fail could also prove useful.</p>