[PATCH] fix PR sanitizer/55617

Jack Howarth howarth@bromo.med.uc.edu
Wed Feb 6 15:05:00 GMT 2013

On Wed, Feb 06, 2013 at 06:23:50PM +0400, Alexander Potapenko wrote:
> 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 <mikestump@comcast.net> wrote:
> > On Feb 4, 2013, at 1:38 AM, Jakub Jelinek <jakub@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.

   I never claimed full init priority support however FSF gcc on darwin currently
has no init priority support at all. Since Mike wanted to sort the destructors as
well as the constructors and this achieves usable intra-module init priority support
for FSF gcc darwin, I don't see why we don't take advantage of it. Especially 
considering that the constructors and destructors will now always be sorted anyway.
ps We will have one advantage over clang's init priority support as we can use -flto
to combine all of the code modules (outside of libraries) into a single one for the
sorting of constructors/destructors. This allows the g++.dg/special/conpr-3.C execution
test case to operate properly on darwin with -flto. Again, remember that clang currently
at least supports init priority on a intra-module level. I am just trying to leverage
the sorting of constructors/destructors that we added for asan to achive the same
level of functionality in FSF gcc on darwin.

> --
> Alexander Potapenko
> Software Engineer
> Google Moscow

More information about the Gcc-patches mailing list