[LLVMdev] recognizing DTORs and vptr updates in LLVM.

[Chris Lattner]

On Mar 19, 2012, at 2:52 PM, Kostya Serebryany 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)

Using instruction level metadata for this would be appropriate.  However, I also don't understand why a race on this is truly benign.  I'm also concerned that you're adding even more knobs to clang and IR for special case situations.  How many more special cases like this are you going to require?

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120319/b6d399c0/attachment.html>