[compiler-rt] [llvm] [asan] Limit priority of ctor to kMax-1 (PR #101772)

[Vitaly Buka via llvm-commits]

vitalybuka wrote:

> > > asan changing the priority of a llvm.global_ctors element might be surprising. Is this change to work with some specific code or specific IR code generators that use 65535 (instrumentation cannot do anything with `.init_array.65535` in inline assembly)? Can we change these tools instead?
> > 
> > 
> > No. The goal to be able to call `asan` runtime callback just after the last dynamic constructor.
> 
> Is there more information about this decision? What would break if the order is different?
> 
> So priority 65535 is unsuffixed `.init_array`. Lots of code might use inline asm `.section .init_array,"aw", at init_array`. Instrumentation cannot safely do anything with them (e.g. adding `.65534` suffix).
> 
> If instrumentation changes IR 65535 elements in `llvm.global_ctors` but not asm `.section .init_array`, this could be risky as well.
> 
> Execution order:
> 
> ```
> a.o:(.init_array.1) b.o:(.init_array.1)
> a.o:(.init_array.2) b.o:(.init_array.2)
> ...
> a.o:(.init_array.65533) b.o:(.init_array.65533)
> a.o:(.init_array.65534) b.o:(.init_array.65534)
> a.o:(.init_array) b.o:(.init_array)
> ```

I see what you mean. :(

> Is there more information about this decision? What would break if the order is different?

There is O(N^2) in init order checking, and it's heavy on our profiles, especial with dynamic linking:

Now we for each TU:
1. poison ALL program globals, except the current TU
2. init globals in TU
3. Unpoison ALL globals
4. repeat

With patches:
1. unpoison globals in prev TU
2. poison globals in the current TU
3. init globals in TU
4. do nothing
5. repeat

But at the end we need to unpoison all globals once, before we get to `main()`
So I didn't figure out a better way to call code reliably at the end of `.init_array`




https://github.com/llvm/llvm-project/pull/101772