Yury Gribov <y.gri...@samsung.com> writes: >[...] >> [mudflap] never reached a point where interoperability across objects with > and without mudflap instrumentation worked > > Could you add more details? E.g. I don't see how mudflap > interoperability is different from AdressSanitizer which seems to be > state of the art.
My sense is that asan and mudflap are comparable with respect to support of interoperation between instrumented and uninstrumented code. The trick is how to handle pointers arriving from the latter. libmudflap handled this issue in two ways: by attempting to intercept all heap allocations from libraries (at the glibc/dlsym level), and by heuristics for recognizing addresses that might have come from unintercepted static/auto allocations. The former is tricky and was an uphill battle trying to catch everything, so in practice heuristics were almost always necessary. (There are of course many differences. They have different tradeoffs as to speed versus memory-consumption - asan is hard-coded in the opposite direction than libmudflap's (configurable) default. asan's multi-threading support may be superior. mudflap's tuning/features were not completed. asan sports more recent developers.) - FChE
