Sanitizers use wrong version of intercepted symbols

[mikea]

Because intercepted symbols are reexported without version information, wrong version of a symbol could be used during runtime. An example would be fmemopen in glibc2.22 (#627)

[morehouse]

@kcc: Is this something we intend to fix at some point?

[kcc]

dunno, nobody complained recently.

[yugr]

This is still a serious issue with Asan interceptors...

[kcc]

@yugr would you like to elaborate?

[yugr]

Glibc exports legacy versions of standard APIs (with different ABIs) so that applications compiled against legacy Glibc's keep working. Asan implements only the latest ABI and does not assign version information to interceptor so it'll intercept calls to legacy ABIs as well. Calling interceptor from code that was compiled against older Glibc will result in runtime crash.

[yugr]

See also #778

[kcc]

let's keep it open in case someone wants to fix this (not me though).
A usual reminder: the today's strategy of using interceptors is absolutely necessary,
but if we want C/C++ to survive long term, we should push towards not having any interceptors
and just have all the code, including libc, always compiled from scratch (and thus instrumented in asan and other modes)

[eugenis]

This is mostly an i386 problem, where glibc has a long history of changes. For example, pthread_mutex_t layout has changed (AFAIR more than once). But that platform is almost gone by now.

As x86_64 matures, we will surely see versioned symbols for common libc functions there as well.