Skip to content
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

Closed
derekbruening opened this issue Nov 28, 2014 · 6 comments
Closed

Comments

@derekbruening
Copy link
Contributor

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

@derekbruening
Copy link
Contributor Author

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.

@derekbruening
Copy link
Contributor Author

Pasting some old notes about other options:

No magic bullet. asm(".symver...") has to be in front of every use, and
some people say they also have to pass --wrap with a dummy impl.

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
non-overlap and doesn't keep strict left-to-right order, hence the version bump.

@derekbruening
Copy link
Contributor Author

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.

@derekbruening
Copy link
Contributor Author

We now have static drinjectlib (on Linux) so drrun itself is all we need to
query now:

# nm ../exports/bin32/drrun | grep ' U .*GLIBC' | grep -v 'GLIBC_2.0'
         U __ctype_b_loc@@GLIBC_2.3
         U fclose@@GLIBC_2.1
         U fopen@@GLIBC_2.1
         U __rawmemchr@@GLIBC_2.1
         U realpath@@GLIBC_2.3

# nm ../exports/bin64/drrun | grep ' U .*GLIBC' | grep -v 'GLIBC_2.2.5'
                 U __ctype_b_loc@@GLIBC_2.3
                 U memcpy@@GLIBC_2.14
                 U realpath@@GLIBC_2.3

The only issue is the memcpy, so I would prefer to address just that than
either use per-symbol version requests or build all exported executables
(drrun, drdeploy, drconfig, nudgeunix, etc.) as pure static.

@derekbruening derekbruening self-assigned this Sep 3, 2015
@derekbruening
Copy link
Contributor Author

We also have:

bin64/runstats
                 U __isoc99_sscanf@@GLIBC_2.7

glibc 2.3 was released Oct 2002, 2.7 Oct 2007, 2.14 June 2011

@derekbruening
Copy link
Contributor Author

This breaks the buildbot which wants glibc 2.4:

$ readelf -s build_release-64/bin64/drconfig | grep 'UND.*GLIBC_2' | grep -v 'GLIBC_2\.2\.'
     2: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __snprintf_chk@GLIBC_2.3.4 (3)
    23: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __realpath_chk@GLIBC_2.4 (4)
    35: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __vsnprintf_chk@GLIBC_2.3.4 (3)
    36: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __strncpy_chk@GLIBC_2.3.4 (3)
    37: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __printf_chk@GLIBC_2.3.4 (3)
    43: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __fprintf_chk@GLIBC_2.3.4 (3)
    41: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __snprintf_chk@@GLIBC_2.3
    47: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __errno_location@@GLIBC_2
   159: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __realpath_chk@@GLIBC_2.4
   299: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __vsnprintf_chk@@GLIBC_2.
   301: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __strncpy_chk@@GLIBC_2.3.
   312: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __printf_chk@@GLIBC_2.3.4
   379: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __fprintf_chk@@GLIBC_2.3.
$ readelf -s build_debug-64/bin64/drconfig | grep 'UND.*GLIBC_2' | grep -v 'GLIBC_2\.2\.'
    30: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND realpath@GLIBC_2.3 (3)
    46: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __errno_location@@GLIBC_2
   220: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND realpath@@GLIBC_2.3

gcc version 4.6.3

derekbruening added a commit that referenced this issue Feb 12, 2019
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
derekbruening added a commit that referenced this issue Feb 12, 2019
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant