On Sun, Feb 3, 2013 at 5:57 AM, Jack Howarth <howa...@bromo.med.uc.edu> wrote: > Currently darwin is unable to utilize libasan with constructors due to the > lack of > constructor priority support on that target. The asan_finish_file routine > inserts an > essential __asan_init into the array of constructors (via the __mod_init_func > section). > However the insertion occurs at the end, and due to the lack of priority > support for > constructors, these are executed from the start of the array of constructors > on program > startup. This causes code any instrumented code that executes before the > __asan_init > call to crash. > Since darwin sets... > > #undef SUPPORTS_INIT_PRIORITY > #define SUPPORTS_INIT_PRIORITY 0 > > in gcc/config/darwin.h, all constructors are automatically set to > > #define DEFAULT_INIT_PRIORITY 65535 > > in gcc/collect2.c. Any code that attempts to set the constructor/destructor > priority > on darwin results in a compile time error of "constructor priorities are not > supported". > So asan alone should be unique in emitting priorities different from 65535 on > darwin. > The attached patch uses a va_gc vector of constructor symbol/priority records > to queue > this data as it is generated in calls to machopic_asm_out_constructor. Any > instances of > the static constructor with priority 99 emitted by asan are inserted safely > in the front > of the vector queue which retains the original order of the remaining > constructors in > the queue. The contents of the vector queue are later processed in a new > finalize_ctors > routine called from darwin_file_end if necessary. The patch also adds a > g++.dg/asan/pr55617.C > test case which is targeted to i?86-*-darwin* and x86_64-*-darwin*. > The patch reduces the failures observed when running.... > > make -k check-g++ RUNTESTFLAGS="--target_board=unix'{-fsanitize=address}'" > > from 323 to only 85 on darwin (similar to the results on linux). The cov.C > testcase also > fails on gcc trunk with -fsanitize=address when recrafted into a dynamic > shared library > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617#c28. This patch eliminates > those > crashes. This problem doesn't extend to when the shared library or module is > dlopen'd > (which works in stock gcc trunk and with this patch as well). > The patch has been bootstrap and regression tested on > x86_64-apple-darwin12. > Okay for gcc trunk?
But that does not work across translation units, no? ISTR collect2 has support to handle constructor priorities all by itself (at link time, considering all inputs). I wonder why darwin cannot use that mechanism to support init priorities? Richard. > Jack > ps Unfortunately the flag_sort variable is unavailable inside of > machopic_asm_out_constructor > so we have to unconditionally test for priority == 99. >