-
Notifications
You must be signed in to change notification settings - Fork 566
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
for libs that use libc, ensure they do not depend on too-recent glibc #1504
Comments
A purely static drrun (linked with static drinjectlib, drconfiglib, libc, and libgcc, and a pure-static exe) is 2.7MB instead of just 48KB so not sure we want that to be the long-term soln. Otherwise avoiding the memcpy@GLIBC_2.14 is going to require setting up a toolchain with a sysroot that has an old glibc. |
Pasting some old notes about other options: No magic bullet. asm(".symver...") has to be in front of every use, and Xref http://stackoverflow.com/questions/8823267/linking-against-older-symbol-version-in-a-so-file It does sound like 64-bit memcpy is the big one: it makes assumptions on |
Maybe this is worth filing as a separate issue, but if we do an Android binary release we should also ensure all our binaries will work with Bionic libc on Android. |
We now have static drinjectlib (on Linux) so drrun itself is all we need to
The only issue is the memcpy, so I would prefer to address just that than |
We also have:
glibc 2.3 was released Oct 2002, 2.7 Oct 2007, 2.14 June 2011 |
This breaks the buildbot which wants glibc 2.4:
gcc version 4.6.3 |
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
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
From [email protected] on August 08, 2014 10:10:23
"For some reason, lib64/libdrinjectlib.so (from the prebuilt binary package)
uses memcpy@GLIBC_2.14 -- and thus it doesn't run on older Linux
distributions, like RHEL6.4."
xref issue #1334 xref drmem-issue #344
Original issue: http://code.google.com/p/dynamorio/issues/detail?id=1504
The text was updated successfully, but these errors were encountered: