libc independence on Linux

From derek.br...@gmail.com on February 24, 2009 11:22:37

I did not yet remove these libc routines:

worried about, but for now only at init: U dlclose@@GLIBC_2.0 U dlopen@@GLIBC_2.1 used only at init: U fclose@@GLIBC_2.1 U feof@@GLIBC_2.0 U fgets@@GLIBC_2.0 U fopen@@GLIBC_2.1 U get_nprocs_conf@@GLIBC_2.0 used only for debugging but will likely be problematic: U getchar@@GLIBC_2.0 U abort@@GLIBC_2.0 U execlp@@GLIBC_2.0 U remove@@GLIBC_2.0 do not use system calls (I did not verify though, just assuming): U __environ@@GLIBC_2.0 U __udivdi3@@GLIBC_2.0 U __umoddi3@@GLIBC_2.0 U backtrace@@GLIBC_2.1 U backtrace_symbols_fd@@GLIBC_2.1 U dlerror@@GLIBC_2.0 U dlsym@@GLIBC_2.0 U getenv@@GLIBC_2.0 U memcpy@@GLIBC_2.0 U memmove@@GLIBC_2.0 U memset@@GLIBC_2.0 U rindex@@GLIBC_2.0 U setenv@@GLIBC_2.0 U sqrt@@GLIBC_2.0 U sscanf@@GLIBC_2.0 U stderr@@GLIBC_2.0 U stdout@@GLIBC_2.0 U strcasecmp@@GLIBC_2.0 U strchr@@GLIBC_2.0 U strcmp@@GLIBC_2.0 U strncasecmp@@GLIBC_2.0 U strncat@@GLIBC_2.0 U strncmp@@GLIBC_2.0 U strncpy@@GLIBC_2.0 U strstr@@GLIBC_2.0 U strtoul@@GLIBC_2.0 U tolower@@GLIBC_2.0

Note that we actually call dlclose at process exit which is potentially a more fragile point then during init. Xref PR 308654 for a crash when we call dlclose.

xref PR 204554: early injection on Linux, which relies on this case, and for which we need to access env vars directly

xref glibc issues with binary compatibility: issue #36

Original issue: http://code.google.com/p/dynamorio/issues/detail?id=46