[LLVMdev] recognizing DTORs and vptr updates in LLVM.

Kostya Serebryany kcc at google.com
Wed Mar 21 11:53:49 PDT 2012


On Tue, Mar 20, 2012 at 1:50 PM, Chris Lattner <clattner at apple.com> wrote:

>
> On Mar 20, 2012, at 12:51 AM, Duncan Sands wrote:
>
> >>> Using instruction level metadata for this would be appropriate.
>  However, I
> >>> also don't understand why a race on this is truly benign.
> >>
> >> It isn't, really; calling it "benign" is deceptive.  It's just that
> >> storing a pointer which is equal to the existing pointer stored at a
> >> given address almost always makes the optimizer/codegen generate code
> >> which can't trigger the race in a way which visibly misbehaves.
> >> Therefore, as a heuristic users apparently want ThreadSanitizer to
> >> ignore (or list separately) such races.
> >
> > The gcc Ada front-end does this too, in quite a range of situations.  For
> > example multiple threads racily initialize a pointer variable, but they
> all
> > initialize to the same value.  The various valgrind based race detection
> > tools all complain about this, which makes them much less useful than
> they
> > might be for Ada.
>
> FWIW, after thinking about this for awhile, I realize that we already have
> the tools to handle this: TBAA.
>
> It would be general goodness for clang to emit VTable loads and stores in
> their with their own TBAA type class (one that does not even alias
> "char*").


Indeed, sounds very nice.
I'll try to make a patch that adds TBAA metadata to VTable loads (unless
someone else knows how to do it off the top of his head).

Thanks!

--kcc


>  This would give us improved code quality, is straight-forward to reason
> about, is not "another knob" and would be a really easy for ASAN to use.
>
> One issue is that TBAA is disabled in -O0 builds: I'd just make vtable
> TBAA information be produced when the optimizer is enabled or if ASAN is
> enabled.
>
> -Chris
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120321/7207a776/attachment.html>


More information about the llvm-dev mailing list