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.
>

Reply via email to