[Bug c/87210] [RFE] introduce build time options to zero initialize automatic stack variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87210 Alexander Potapenko changed: What|Removed |Added CC||glider at google dot com --- Comment #4 from Alexander Potapenko --- To give an update, upstream Clang now supports force initialization of stack variables under the -ftrivial-auto-var-init flag. -ftrivial-auto-var-init=pattern initializes local variables with a 0xAA pattern (actually it's more complicated, see https://reviews.llvm.org/D54604) -ftrivial-auto-var-init=zero provides zero-initialization of locals. This mode isn't officially supported yet and is hidden behind an additional -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang flag. This is done to avoid creating a C++ dialect where all variables are zero-initialized. Starting v5.2, Linux kernel has a CONFIG_INIT_STACK_ALL config that performs the build with -ftrivial-auto-var-init=pattern. This one isn't widely adopted yet, partially because initializing locals with 0xAA isn't fast enough. Linus Torvalds is quite positive about zero-initializing the locals though, see https://lkml.org/lkml/2019/7/30/1303 So having a flag similar to -ftrivial-auto-var-init=zero in GCC will be appreciated by the Linux kernel community.
[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 --- Comment #6 from Alexander Potapenko --- The problem is caused by _NSGetEnviron() being called before libSystem is initialized. This happens because some initialization code calls __cxa_atexit() before libSystem_initialize(), and __cxa_atexit() calls __asan_init() and _NSGetEnviron(). The fix is trivial (call the real __cxa_atexit() if asan_inited == 0 instead of calling __asan_init()), but before landing it I'll check why the crash doesn't happen on LLVM (I suspect different linkage order).
[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 --- Comment #7 from Alexander Potapenko --- If I compile stack-overflow-1.c with 'clang -fsanitize=address -c', the resulting object file can be linked into an executable with either 'clang -fsanitize=address' or 'gcc -fsanitize=address' (this requires declaring "void *__asan_mapping_offset=0x1000;", since the GCC instrumentation pass doesn't insert the mapping offset). The executable linked with Clang works just fine, while the GCC one crashes on the same env_ptr assertion. Clang: $ $CLANG stack-overflow-1.o -fsanitize=address -v && ./a.out ... "/usr/bin/ld" -dynamic -arch x86_64 -macosx_version_min 10.8.0 -o a.out stack-overflow-1.o -lstdc++ /Users/glider/src/asan/llvm/llvm_cmake_build/bin/../lib/clang/3.4/lib/darwin/libclang_rt.asan_osx_dynamic.dylib -lSystem = ==37032==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff5add8aea at pc 0x104e27c93 bp 0x7fff5add89f0 sp 0x7fff5add89e8 ... GCC: $ $GCC stack-overflow-1.o -fsanitize=address -v && ./a.out ... /usr/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.8.5 -weak_reference_mismatches non-weak -o a.out -L/Users/glider/src/gcc-asan/build/inst/lib/gcc/x86_64-apple-darwin12.5.0/4.9.0 -L/Users/glider/src/gcc-asan/build/inst/lib/gcc/x86_64-apple-darwin12.5.0/4.9.0/../../.. stack-overflow-1.o -lasan -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lSystem -v ... ==37029==AddressSanitizer CHECK failed: ../../../../libsanitizer/sanitizer_common/sanitizer_mac.cc:146 "((env_ptr)) != (0)" (0x0, 0x0) This seems to have nothing to do with the linkage order: I've tried to change the order of -l flags in the ld invocation from $GCC, but that didn't work. However when I replaced '-lasan' with the full path to the ASan runtime from the Clang build, it worked fine. So there's some subtle difference between the ASan runtimes compiled when building GCC and Clang.
[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 --- Comment #8 from Alexander Potapenko --- Clang's libclang_rt.asan_osx_dynamic.dylib depends on the Foundation framework. When I remove that dependency, ASanified programs crash on the same env_ptr assertion.
[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 --- Comment #10 from Alexander Potapenko --- This might help, but we don't actually need that dependency. Instead libsanitizer should be updated to r194573.
[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 --- Comment #12 from Alexander Potapenko --- That was Foundation, not sure if CoreFoundation also works.
[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 --- Comment #14 from Alexander Potapenko --- I think one of the frameworks depends on another one, please make sure to pick the latter one if that's true. Also add a comment denoting this is a dirty workaround. On Nov 13, 2013 9:38 PM, "howarth at nitro dot med.uc.edu" < gcc-bugzi...@gcc.gnu.org> wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 > > --- Comment #13 from Jack Howarth --- > (In reply to Alexander Potapenko from comment #12) > > That was Foundation, not sure if CoreFoundation also works. > > Linking libasan against -Wl,-framework,CoreFoundation for gcc trunk at > r204750 > suppresses all of the failures in asan.exp on x86_64-apple-darwin12. > Retesting > with -Wl,-framework,Foundation. > > -- > You are receiving this mail because: > You are on the CC list for the bug. >
[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 --- Comment #16 from Alexander Potapenko --- I've actually removed the Foundation linkage from LLVM today. On Nov 13, 2013 10:45 PM, "howarth at nitro dot med.uc.edu" < gcc-bugzi...@gcc.gnu.org> wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 > > --- Comment #15 from Jack Howarth --- > (In reply to Alexander Potapenko from comment #14) > > I think one of the frameworks depends on another one, please make sure to > > pick the latter one if that's true. > > Also add a comment denoting this is a dirty workaround. > > On Nov 13, 2013 9:38 PM, "howarth at nitro dot med.uc.edu" < > > gcc-bugzi...@gcc.gnu.org> wrote: > > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 > > > > > > --- Comment #13 from Jack Howarth > --- > > > (In reply to Alexander Potapenko from comment #12) > > > > That was Foundation, not sure if CoreFoundation also works. > > > > > > Linking libasan against -Wl,-framework,CoreFoundation for gcc trunk at > > > r204750 > > > suppresses all of the failures in asan.exp on x86_64-apple-darwin12. > > > Retesting > > > with -Wl,-framework,Foundation. > > > > > > -- > > > You are receiving this mail because: > > > You are on the CC list for the bug. > > > > > The Foundation framework is already linked against the CoreFoundation > framework. I've confirmed that linking libasan against > -Wl,-framework,Foundation alone (as is done by llvm) is sufficient to > suppress > the asan.exp failures. This change will duplicate the linkage used by llvm > for > the asan shared library. Posted proposed patch at > http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01499.html, > > -- > You are receiving this mail because: > You are on the CC list for the bug. >
[Bug sanitizer/59148] FAIL: c-c++-common/asan/strncpy-overflow-1.c -O0 execution test on darwin13
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59148 --- Comment #3 from Alexander Potapenko --- GCC emits calls to __strcpy_chk and __strncpy_chk in this test, which happens because of source fortification being on by default on Darwin. In Clang we're passing -D_FORTIFY_SOURCE=0 when compiling with -fsanitize=address. I've checked that manually adding -D_FORTIFY_SOURCE=0 fixes strncpy-overflow-1.c Jack, can you please make the changes in the GCC driver?
[Bug sanitizer/59148] FAIL: c-c++-common/asan/strncpy-overflow-1.c -O0 execution test on darwin13
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59148 --- Comment #5 from Alexander Potapenko --- I've opened https://code.google.com/p/address-sanitizer/issues/detail?id=247 to track this. But until that issue is fixed we'll have to disable source fortification in GCC if ASan is enabled.
[Bug sanitizer/59369] c-c++-common/asan/pr59063-[1,2].c fails on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59369 --- Comment #3 from Alexander Potapenko --- Should be fine to disable this test on Darwin due to what Yury said.
[Bug sanitizer/59136] [4.9 Regression] llvm-symbolizer shouldn't be started always
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59136 --- Comment #12 from Alexander Potapenko --- I wonder if https://code.google.com/p/address-sanitizer/issues/detail?id=253 is relevant here. In the case TSan tests do fork() (which I'm not expecting from them, however) the parent and the child will share the same symbolizer, which will just fail to multiplex their queries.
[Bug bootstrap/55289] darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289 Alexander Potapenko changed: What|Removed |Added CC||glider at google dot com --- Comment #28 from Alexander Potapenko 2012-11-14 16:13:47 UTC --- === t.o: file format mach-o-x86-64 Disassembly of section .text: <_foo>: 0:55 push %rbp 1:48 89 e5 mov%rsp,%rbp 4:90 nop 5:90 nop 6:90 nop 7:90 nop 8:48 8d 05 11 4f 0b 00 lea0xb4f11(%rip),%rax# b4f20 <_foo.eh+0xb4ee8> f:53 push %rbx 10:48 8d 5f e0 lea-0x20(%rdi),%rbx 14:48 89 77 90 mov%rsi,-0x70(%rdi) 18:5d pop%rbp 19:c3 retq === mach_override must be choking on the lea instruction. The easiest way to handle it is to add "48 8d 05 00 00 00 00" to the list of instructions and mark it as "lea $imm(%rip),%rax". You can also dive into the opcodes a bit and mask the bits that select the destination register. I'll take a look at mach_override.c code to suggest the actual patch.
[Bug bootstrap/55289] darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289
--- Comment #29 from Alexander Potapenko 2012-11-14
16:40:53 UTC ---
Index: mach_override.c
===
--- mach_override.c(revision 167724)
+++ mach_override.c(working copy)
@@ -725,6 +725,8 @@
{ 0x2, {0xFF, 0x00}, {0x89, 0x00} }, //
mov r/m32,r32 or r/m16,r16
{ 0x3, {0xFF, 0xFF, 0xFF}, {0x49, 0x89, 0xF8} }, //
mov %rdi,%r8
{ 0x4, {0xFF, 0xFF, 0xFF, 0xFF}, {0x40, 0x0F, 0xBE, 0xCE} }, //
movsbl %sil,%ecx
+{ 0x7, {0xFF, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00},
+ {0x48, 0x8D, 0x05, 0x00, 0x00, 0x00, 0x00} }, // lea
$imm(%rip),%rax
{ 0x3, {0xFF, 0xFF, 0xFF}, {0x0F, 0xBE, 0xCE} }, // movsbl, %dh, %ecx
{ 0x3, {0xFF, 0xFF, 0x00}, {0xFF, 0x77, 0x00} }, // pushq $imm(%rdi)
{ 0x2, {0xFF, 0xFF}, {0xDB, 0xE3} }, // fninit
===
Please also make sure the interceptors work in 32-bit programs
[Bug bootstrap/55289] darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289 --- Comment #39 from Alexander Potapenko 2012-11-15 08:18:01 UTC --- I agree with Kostya that no major changes to mach_override are necessary because we are really going to dump it. However minor fixes required for ASan in GCC to work on Darwin right now should be perfectly ok. As there currently are issues blocking the dynamic ASan runtime (e.g. https://code.google.com/p/address-sanitizer/issues/detail?id=124), and we still depend on CoreFoundation I can't promise that we'll get rid of mach_override before the GCC 4.8 release.
[Bug sanitizer/55289] darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289 --- Comment #49 from Alexander Potapenko 2012-11-22 10:43:03 UTC --- The new interposition library should work on 10.6. But ASan itself doesn't work on 10.5, at least I remember some problems with its compilation. We're not really interested in supporting 10.5, as it's completely unsupported by Apple.
[Bug sanitizer/55599] switch from mach_override to mac interpose function support in libasan broke -static-libasan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55599 --- Comment #2 from Alexander Potapenko 2012-12-05 01:07:36 UTC --- Not that it prohibits the use of static ASan, they just currently can't coexist in a single program with the current setup. It is theoretically possible to have them both, although we definitely do not want to. I'm guessing that the link problems have been caused by the removal of mach_override from the tree.
[Bug sanitizer/55599] switch from mach_override to mac interpose function support in libasan broke -static-libasan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55599 --- Comment #5 from Alexander Potapenko 2012-12-05 04:50:43 UTC --- The dynamic interposition library is based on the __DATA,__interpose dyld feature (see http://toves.freeshell.org/interpose/ or Amit Singh's "Mac OS X Internals" book), which strictly requires the interposing functions to be in a shared library that must be preloaded using DYLD_INSERT_LIBRARIES (ASan does that automatically in __asan_init) The dynamic library doesn't require the mach_override code (we don't link it in LLVM), but the static one does. Since you have removed the mach_override code, it's time to drop the static library support (note that in LLVM the static runtime library is still the default one, because it's now the one that simply works)
[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617
Alexander Potapenko changed:
What|Removed |Added
CC||glider at google dot com
--- Comment #5 from Alexander Potapenko 2013-01-29
09:49:44 UTC ---
Here's a smaller repro for this problem:
$ cat cov.cc
struct c18 {
virtual void bar() { }
};
c18 ret;
int main () {
}
=
$ inst/bin/g++ -fsanitize=address cov.cc -o cov -g
$ gdb cov
(gdb) r
Starting program: /Users/glider/src/gcc_failures/asan_g++_failures/cov
Reading symbols for shared libraries . done
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x1000221c
0x00010dd2 in c18::c18 (this=0x110e0) at cov.cc:1
1 struct c18 {
(gdb) bt
#0 0x00010dd2 in c18::c18 (this=0x110e0) at cov.cc:1
#1 0x00010d5a in __static_initialization_and_destruction_0
(__initialize_p=1, __priority=65535) at cov.cc:4
#2 0x00010d6f in _GLOBAL__sub_I_cov.cc () at cov.cc:6
#3 0x7fff5fc13378 in
__dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE
()
#4 0x7fff5fc13762 in
__dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE
()
#5 0x7fff5fc1006e in
__dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE
()
#6 0x7fff5fc0feba in
__dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextERNS_21InitializerTimingListE
()
#7 0x7fff5fc01fc0 in __dyld__ZN4dyld24initializeMainExecutableEv ()
#8 0x7fff5fc05b04 in
__dyld__ZN4dyld5_mainEPK12macho_headermiPPKcS5_S5_Pm ()
#9 0x7fff5fc01397 in
__dyld__ZN13dyldbootstrap5startEPK12macho_headeriPPKclS2_Pm ()
#10 0x7fff5fc0105e in __dyld__dyld_start ()
[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617 --- Comment #6 from Alexander Potapenko 2013-01-29 09:59:09 UTC --- Looking at the disassembly I see that __asan_init is placed into some __GLOBAL__sub_I_00099_1_cov.cc function, which isn't being called at runtime (__GLOBAL__sub_I_cov.cc is called instead): 00010d31 <__Z41__static_initialization_and_destruction_0ii>: 10d31: 55 push %rbp 10d32: 48 89 e5mov%rsp,%rbp 10d35: 48 83 ec 10 sub$0x10,%rsp 10d39: 89 7d fcmov%edi,-0x4(%rbp) 10d3c: 89 75 f8mov%esi,-0x8(%rbp) 10d3f: 83 7d fc 01 cmpl $0x1,-0x4(%rbp) 10d43: 75 15 jne10d5a <__Z41__static_initialization_and_destruction_0ii+0x29> 10d45: 81 7d f8 ff ff 00 00cmpl $0x,-0x8(%rbp) 10d4c: 75 0c jne10d5a <__Z41__static_initialization_and_destruction_0ii+0x29> 10d4e: 48 8d 3d 8b 03 00 00lea0x38b(%rip),%rdi# 110e0 <_ret> 10d55: e8 9c 00 00 00 callq 10df6 <__ZN3c18C1Ev$stub> 10d5a: c9 leaveq 10d5b: c3 retq 00010d5c <__GLOBAL__sub_I_cov.cc>: 10d5c: 55 push %rbp 10d5d: 48 89 e5mov%rsp,%rbp 10d60: be ff ff 00 00 mov$0x,%esi 10d65: bf 01 00 00 00 mov$0x1,%edi 10d6a: e8 c2 ff ff ff callq 10d31 <__Z41__static_initialization_and_destruction_0ii> 10d6f: 5d pop%rbp 10d70: c3 retq 00010d71 <__GLOBAL__sub_D_00099_0_cov.cc>: 10d71: 55 push %rbp 10d72: 48 89 e5mov%rsp,%rbp 10d75: be 01 00 00 00 mov$0x1,%esi 10d7a: 48 8d 3d 1f 03 00 00lea0x31f(%rip),%rdi# 110a0 <__ZTI3c18+0x20> 10d81: e8 88 00 00 00 callq 10e0e <___asan_unregister_globals$stub> 10d86: 5d pop%rbp 10d87: c3 retq 00010d88 <__GLOBAL__sub_I_00099_1_cov.cc>: 10d88: 55 push %rbp 10d89: 48 89 e5mov%rsp,%rbp 10d8c: e8 6b 00 00 00 callq 10dfc <___asan_init$stub> 10d91: be 01 00 00 00 mov$0x1,%esi 10d96: 48 8d 3d 03 03 00 00lea0x303(%rip),%rdi# 110a0 <__ZTI3c18+0x20> 10d9d: e8 60 00 00 00 callq 10e02 <___asan_register_globals$stub> 10da2: 5d pop%rbp 10da3: c3 retq
[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617 --- Comment #7 from Alexander Potapenko 2013-01-29 11:56:02 UTC --- Here's the dump of __mod_init_func (the static ctors array): === Disassembly of section __DATA.__mod_init_func: 00011040 <__DATA.__mod_init_func>: 11040: 5c pop%rsp 11041: 0d 00 00 01 00 or $0x1,%eax 11046: 00 00 add%al,(%rax) 11048: 88 0d 00 00 01 00 mov%cl,0x1(%rip)# 10001104e <_ret+0xff6e> === -- Looks like both __GLOBAL__sub_I_00099_1_cov.cc (00010d88, which is the analog of _asan.module_ctor in Clang instrumentation) and __GLOBAL__sub_I_cov.cc (00010d5c, the original module ctor) are present in __mod_init_func, but are ordered incorrectly. I've fixed the order using bvi for OS X: === 00011040 <__DATA.__mod_init_func>: 11040: 88 0d 00 00 01 00 mov%cl,0x1(%rip)# 100011046 <_ret+0xff66> 11046: 00 00 add%al,(%rax) 11048: 5c pop%rsp 11049: 0d 00 00 01 00 or $0x1,%eax === and the resulting binary didn't segfault for me.
[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617 --- Comment #10 from Alexander Potapenko 2013-01-30 12:29:00 UTC --- I suppose this isn't important. __mod_term_func are destructors, and they even aren't called in the crashing program.
[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617 --- Comment #12 from Alexander Potapenko 2013-01-30 14:32:54 UTC --- > The question is why does... > > if (builtin_decl_implicit_p (BUILT_IN_ASAN_INIT)) > return; > > in initialize_sanitizer_builtins() not emit a __asan_init while apparently... I'm guessing initialize_sanitizer_builtins() just warms something up, but doesn't actually emit any code. IANAGCCH though. > tree fn = builtin_decl_implicit (BUILT_IN_ASAN_INIT); > > in asan_finish_file() emits an apparenty unnecessary one in the wrong section. This one is a necessary one. asan_finish_file inserts __asan_init into the array of constructors (aka __mod_init_func section). But for some reason it is inserted at the end of that array, while the constructors are being executed from the start of the array at program startup. That's why the program crashes (because it's trying to execute some instrumented code that accesses the shadow memory, which isn't mapped yet), and the real question is how do we put the new constructor first provided that the ctor priorities do not work well on Darwin.
[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617 --- Comment #20 from Alexander Potapenko 2013-01-30 17:07:25 UTC --- (In reply to comment #19) > Well, if somebody does the work and in a clean way that won't penalize targets > with sane linkers and object formats, I'm not objecting, I just am not going > to > spend time on this. If clang can handle ctor priorities right at least inside > of each individual CUs, perhaps those that care about targets which don't > support that in the linker can add similar support to gcc (what I've been > suggesting, if priorities aren't supported by linker, don't emit stuff right > away, but just queue it and at the end sort it and emit. Looks like you're right and the constructors are just being emitted by machopic_asm_out_constructor() in gcc/config/darwin.c, so ASan just has no chance to add his ctor before the default one. I suppose this can be fixed in gcc/config/darwin.c, but we don't have enough knowledge and/or cycles for this. Perhaps the right thing to do is to file a bug against the owner of that file.
[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617 --- Comment #21 from Alexander Potapenko 2013-01-30 17:30:18 UTC --- Created attachment 29309 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29309 Dummy patch that reverses the order of the constructors Attached is a hacky POC patch that intends to just reverse the order of constructors in the module. It fixes the current problem with ASan ctor being the last one (it is the first one now), yet it doesn't fix the missing support for priorities. It also contains a fixed-size array of ctors, which needs to be replaced with some dynamic structure. I also have no idea what rtx is and whether it remains allocated throughout the compilation or we're just using dangling pointers.
[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617 --- Comment #48 from Alexander Potapenko 2013-02-04 10:11:32 UTC --- (In reply to comment #40) > if (ctor_recA->position > ctor_recB->position) > return -1; > if (ctor_recA->position < ctor_recB->position) > return 1; > > This is wrong. I think we want this reversed as well. We want original > order. > A testcase with two ctors, should in the end have the one with the lower > original position first. > > So, for me to approve it, I need to know if sorting just inside 1 translation > unit is enough to make -fsanitize=address work. I fear the answer to that is > no, and without cross translation unit support, this is just bug pushing > (obscuring a bug with a non-fix that just makes fixing it even harder). I > won't approve it if it is bug pushing. If cross has to work, then cross > shared > libraries I suspect has to work as well. In LLVM this is done without cross-TU: we just emit a call to __asan_init per TU and append it to the list of global constructors for the current module (note that the constructors' priorities on Darwin do not work across modules at all: http://llvm.org/bugs/show_bug.cgi?id=12556
[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617 --- Comment #49 from Alexander Potapenko 2013-02-04 10:13:49 UTC --- I agree with Jakub: it's better to return back to the qsort version of the patch, since it fixes ASan as well, but also provides better support for priorities in general.
