[PATCH] fix PR sanitizer/55617

Jack Howarth howarth@bromo.med.uc.edu
Mon Feb 4 14:22:00 GMT 2013

On Mon, Feb 04, 2013 at 10:38:29AM +0100, Jakub Jelinek 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 switched to the simple insertion of the asan priorities for two reasons...

1) Mike seemed unconvinced that the single qsort with the proposed sort_ctor_records

+static int
+sort_ctor_records (const void * a, const void * b)
+  const ctor_record *ca = (const ctor_record *)a;
+  const ctor_record *cb = (const ctor_record *)b;
+  if (ca->priority > cb->priority)
+    return 1;
+  if (ca->priority < cb->priority)
+    return -1;
+  if (ca->position > cb->position)
+    return -1;
+  if (ca->position < cb->position)
+    return 1;
+  return 0;

would really be stable in absence of a second call to qsort.

2) Once I realized that darwin sets the default priority of constructors to
DEFAULT_INIT_PRIORITY 65535, the desired sorting method seemed rather unclear.
I assume we need to really sort these so that the priorities from 
MAX_INIT_PRIORITY-1 through 0 appear first in the queue and then those with
MAX_INIT_PRIORITY, right? It isn't obvious how we can achieve that in
sort_ctor_record with a single pass through qsort.

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

More information about the Gcc-patches mailing list