I can't see how full init_priority support can work without proper aid from ld and/or the dynamic linker. According to the Apple people, those don't treat the cross-module priorities properly, so there's little that can be done on the compiler side.
On Mon, Feb 4, 2013 at 11:39 PM, Mike Stump <mikest...@comcast.net> wrote: > On Feb 4, 2013, at 1:38 AM, Jakub Jelinek <ja...@redhat.com> wrote: >> On Mon, Feb 04, 2013 at 10:22:48AM +0100, Richard Biener wrote: >>>> 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 the patch turned from initially at least supporting intra-CU >> support for ctor priorities into an ugly hack for asan. I guess asan >> doesn't care too much about inter-CU ctor priorities, it just needs its >> ctors to run before anything in the same CU is called (mainly the >> __asan_init call), other CUs either won't be asan instrumented, then it >> doesn't matter, or will be, but they will have their own __asan_init call. >> >>> I wonder why darwin cannot use that mechanism to support init priorities? >> >> But sure, if collect2 can be used for full init prio support, the better. > > It would be nice if someone contributed full init_priority support… I'd be > happy to review that. A good patch for that would add it to clang for darwin, > and have gcc use that same mechanism so that we can interoperate nicely. > Absent interoperability… I think it would be annoying, as then you have to > have a binary incompatibility to fix the one that is wrong. -- Alexander Potapenko Software Engineer Google Moscow
