[LLVMdev] recognizing DTORs and vptr updates in LLVM.

[Eli Friedman]

On Mon, Mar 19, 2012 at 2:52 PM, Kostya Serebryany <kcc at google.com> wrote:
> Hello,
>
> While instrumenting LLVM IR in ThreadSanitizer (race detector), I need
> to distinguish between a store to vtable pointer (vptr) and any other
> regular store.
> This special treatment should be limited to class DTORs, so I should also
> know when a function is a DTOR.
> Rationale: need to distinguish benign and harmful races on vptr
> (http://code.google.com/p/data-race-test/wiki/PopularDataRaces#Data_race_on_vptr).
>
> Currently, I can figure out when a function is a DTOR and when a store
> touches vptr by analyzing mangled names.
> _ZN1BD1Ev=="B::~B()"
> _ZTV1B=="vtable for B"
>
> define linkonce_odr void @_ZN1BD1Ev(%struct.B* %this) unnamed_addr nounwind
> uwtable align 2 {
> entry:
>   ....
>   store i32 (...)** bitcast (i8** getelementptr inbounds ([5 x i8*]*
> @_ZTV1B, i64 0, i64 2) to i32 (...)**), i32 (...)*** %0, align 8
>
> However, this does not sound right.
> What would be the right way to pass this information from clang to LLVM?
> Will using metadata for this purpose be a right solution?
> (insn-level metadata for vptr store and module-level metadata for DTORs)

It's worth pointing out the according to the abstract LLVM IR model,
your "benign" races are in fact undefined behavior.  The only reason
it appears to work is that in practice non-atomic loads and stores
usually result in the same generated code as "relaxed" atomic loads
and stores.  If we are in fact supposed to guarantee some sort of
behavior here, we should generate an atomic store.  If we aren't, I'm
not sure why AddressSanitizer needs to distinguish between "usually
appears to work" and "almost always appears to work".

-Eli