Apply changes from CSE's current dcc version related to the hack for glib2.27/clang6.0 on 32bit userspace

[andrewjbennett]

Not sure whether you're concerned about the repo being up-to-date with what's currently on CSE.

This PR has the patch for the dodgy hack I added to allow dcc to still compile/run when CSE briefly upgraded to glib 2.27 with clang 6.0 where everything exploded.

This patch isn't necessary for older glib versions, or for a 64 bit userspace, and thus hopefully won't be necessary soon, but....

[andrewjbennett]

Relevant information from the email thread at that time:

---

It appears that all programs compiled with dcc crash immediately when you run them.
This also happens for binaries that were compiled with dcc weeks ago (which worked at the time).

Reported by a student on vx3, verified by me on wagner.

z3378327@wagner:~/test$ cat hello.c
#include <stdio.h>
int main(void) {
	printf("Hello!\n");
	return 0;
}
z3378327@wagner:~/test$ dcc -o hello hello.c
z3378327@wagner:~/test$ ./hello
AddressSanitizer:DEADLYSIGNAL
=================================================================
Usage: /home/cs1911/bin/dcc [--valgrind|--memory|--no_explanation] <c-files>

---

It looks like it's an issue with ASAN and glibc 2.27+

https://reviews.llvm.org/rL334363
google/sanitizers#954

---

Yep it's an ASAN library issue

weill:~% echo "int main(void) {}"|clang -fsanitize=address -x c - &&./a.out
AddressSanitizer:DEADLYSIGNAL
=================================================================
==24744==ERROR: AddressSanitizer: SEGV on unknown address 0xf779e430 (pc 0xf779e444 bp 0xffa7ba6c sp 0xffa7ba2c T16777215)
==24744==The signal is caused by a WRITE memory access.
    #0 0xf779e443 in _dl_get_tls_static_info (/lib/ld-linux.so.2+0x12443)
    #1 0x8159e89 in __sanitizer::InitTlsSize() (/tmp_amd/adams/export/adams/1/andrewt/a.out+0x8159e89)
    #2 0x813ed32 in __asan::AsanInitInternal() [clone .part.3] (/tmp_amd/adams/export/adams/1/andrewt/a.out+0x813ed32)
    #3 0xf779beda  (/lib/ld-linux.so.2+0xfeda)
    #4 0xf778d299  (/lib/ld-linux.so.2+0x1299)

---

Last night, Libc6 got a modest update and Clang was upgraded from v4 to v6. (GCC also upgraded v7 -> v8)

Those changed together because those bundles from Debian Testing are compiled to work together.

---

The previous libc6 set (v 2.26 replacing v2.27) is deployed back just about everywhere now.