0

my situation is that I created a compile time instrumentation system that inserts code in an application that does some book-keeping of it's internal state for dynamic analysis purposes. The injected code relies on a runtime library that implements the necessary data structures.

In order to improve the accuracy of my tool, I want to track changes to internal state inside calls to libc. To this end, I have compiled an instrumented version of musl.

The problem is that my runtime library relies on glibc for various reasons (can't change this). How do I go about letting the application use the instrumented musl symbols, but let the runtime library use the plain glibc symbols?

Daniel Grumberg
  • 21
  • 3
  • 1
    To be clear: you want to use GLIBC and Musl in the same process? I don't think this is a reasonable approach or that it will ever work. – Employed Russian Oct 20 '19 at 20:23
  • I fixed this but I will add my solution FTR, so the idea was to be able to keep track of additional info about memory operations across libc calls via instrumentation. The solution I went with was to instrument musl, rename the symbols so they don't clash with libc, link them into the application like you would any static library and then use the dynamic glibc to provide the actual libc that winds up only being used for my runtime components. – Daniel Grumberg Oct 21 '19 at 10:47

0 Answers0