https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82501
--- Comment #20 from Martin Liška <marxin at gcc dot gnu.org> --- (In reply to Andrey Drobyshev from comment #18) > (In reply to Martin Liška from comment #16) > > Created attachment 45797 [details] > > Patch candidate > > > > Patch candidate where I made some refactoring and come up with tests. > > Works fine on x86_64, on ppc64le there are some issues with > > -fsection-anchors, but that would be possible to resolve. > > > > Please let me know if you're fine with that and we can submit that to > > gcc-patches ML? > > Looks good to me. By not setting TREE_PUBLIC flag we give our dummy globals > internal linkage (as if they were static), thus allowing linker to mix > multiple TUs with these dummies. One can't use TREE_PUBLIC because: $ cat a.c int a = 2; $ cat b.c int b = 3; $ gcc a.c b.c -fsanitize=address /usr/bin/ld: /tmp/ccSj1xmO.o:(.data+0x0): multiple definition of `__asan_data_dummy_global'; /tmp/ccsHDJug.o:(.data+0x0): first defined here /usr/bin/ld: /usr/lib/../lib64/crt1.o: in function `_start': /home/abuild/rpmbuild/BUILD/glibc-2.29/csu/../sysdeps/x86_64/start.S:104: undefined reference to `main' collect2: error: ld returned 1 exit status > > However, this way number of dummy globals in the resulting executable is > proportional to the number of TUs, and each of them occupies additional 64b > for redzone (due to alignment) + its poisoned metadata (struct > __asan_global, also 64b on x86_64). I guess that's what was meant by > "wasting more memory" in > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82501#c1. I'm not sure, are we > ok with such a waste? Yes, I hope it's a reasonable trade off.
