i#3315: avoid conflicts with memset and memcpy #3374
Conversation
Core DR's copies of memset and memcpy were placed into drhelper to avoid glibc-versioned symbols in our shipped binaries (#1504). They are linked into the static drfrontendlib and drinjectlib libraries. They are also in core DR when built as a static library. In these static library cases they can conflict with symbols of the same name elsewhere in the linking application. To solve this, we first separate memset and memcpy from drhelper into their own library, drmemfuncs. We simply avoid linking it into static core DR, and into drdecode. For static core DR we assume that whatever versions the application or glibc provides will be re-entrant. We can't avoid linking it into drfrontendlib and drinjectlib (we hit the glibc versioning problem), but we reduce the chance of conflicts with these libraries by marking memset and memcpy as weak. Fixes #3315
| * those definitions and intercept them. In particular, this occurs when | ||
| * running an app that links in the Address Sanitizer runtime. Since we already | ||
| * need a reasonably efficient assembly memcpy implementation for safe_read, we | ||
| * go ahead and reuse the code for private memcpy and memset. |
There was a problem hiding this comment.
I don't see an explicit reference to safe_read in here, but im guessing the comment is referring to these macros which might be shared? Do you mind clearing up exactly what parts or shared, or fixing this comment up if the following functions don't actually reuse stuff which is specifically for safe_read?
There was a problem hiding this comment.
safe_read_asm shares the REP_STRING_OP macro which is also used here.
This comment does bring up something I did not make clear in the issue: there is a downside to having static DR use glibc memcpy. It lets sanitizers or other interceptors override
DR's memcpy. However, we already have interoperability concerns with sanitizers, so I was assuming we could live with that.
There was a problem hiding this comment.
I want to also add the sanitizer concern to the code comments and not just the issue so I can send you a comment update PR.
Core DR's copies of memset and memcpy were placed into drhelper to
avoid glibc-versioned symbols in our shipped binaries (#1504).
They are linked into the static drfrontendlib and drinjectlib
libraries. They are also in core DR when built as a static library.
In these static library cases they can conflict with symbols of the
same name elsewhere in the linking application.
To solve this, we first separate memset and memcpy from drhelper into
their own library, drmemfuncs. We simply avoid linking it into static
core DR, and into drdecode. For static core DR we assume that
whatever versions the application or glibc provides will be
re-entrant.
We can't avoid linking it into drfrontendlib and drinjectlib (we hit
the glibc versioning problem), but we reduce the chance of conflicts
with these libraries by marking memset and memcpy as weak.
Fixes #3315