Constructor priorities on Darwin aren't supposed to work across
translation units, see http://llvm.org/bugs/show_bug.cgi?id=12556:
"""
I was told (by Apple folks) that darwin does not support cross-unit constructor
priorities, sorry. This is true for both gcc and llvm-gcc / clang. Within unit
priorities are emulated on darwin (via emission order).
Also, according to Nick Kledzik, constructors are executed on darwin strictly
in link order. So, when you link foo.o and bar.o, then first ctors from foo.o
are executed, then - from bar.o. Maybe this is even documented in some MachO
docs.
"""
Yet it should be possible to delay the constructor emission for a
single TU until all the compiler passes do their job, and then sort
those constructors according to their priorities.
On Mon, Feb 4, 2013 at 1:22 PM, Richard Biener
<richard.guent...@gmail.com> wrote:
> 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.
>>
--
Alexander Potapenko
Software Engineer
Google Moscow
