Description of problem:
The following issue is observed in all `ld` versions >= 2.21. Version 2.20 does not exhibit this behavior.
A simple C file:
#include <stdio.h>
extern char **environ;
int main(int argc, char **argv) {
printf("%p\n", environ);
return 0;
}
When compiled, will reference `_environ`:
$ gcc -o environ environ.c && \
readelf -s environ | grep " _environ"
4: 0000000000601040 8 OBJECT WEAK DEFAULT 24 _environ.5 (2)
$
When compiled passing the linker `--gc-sections`, the `_environ` alias is dropped, but the `__environ` and `environ` ones remain:
$ gcc -Wl,--gc-sections -o environ environ.c && \
readelf -s environ | grep " _environ"
$
This breaks glibc functionality that looks at `_environ` internally, because it then points to a different address when the shared object is loaded. This manifested in glibc not respecting memory sub-system environment variables.
Description of problem: The following issue is observed in all `ld` versions >= 2.21. Version 2.20 does not exhibit this behavior. A simple C file: #include <stdio.h> extern char **environ; int main(int argc, char **argv) { printf("%p\n", environ); return 0; } When compiled, will reference `_environ`: $ gcc -o environ environ.c && \ readelf -s environ | grep " _environ" 4: 0000000000601040 8 OBJECT WEAK DEFAULT 24 _environ.5 (2) $ When compiled passing the linker `--gc-sections`, the `_environ` alias is dropped, but the `__environ` and `environ` ones remain: $ gcc -Wl,--gc-sections -o environ environ.c && \ readelf -s environ | grep " _environ" $ This breaks glibc functionality that looks at `_environ` internally, because it then points to a different address when the shared object is loaded. This manifested in glibc not respecting memory sub-system environment variables.