[llvm-dev] [RFC] Design of a TBAA sanitizer
Sanjoy Das via llvm-dev
llvm-dev at lists.llvm.org
Tue Apr 11 17:56:10 PDT 2017
Hi Kostya,
On Tue, Apr 11, 2017 at 5:45 PM, Kostya Serebryany <kcc at google.com> wrote:
>> p0 = malloc()
>> free(p0)
>> p1 = malloc()
>> *p0 = 20 // S0
>> *p1 = 20 // S1
>>
>> then S0 and S1 would have been okay to reorder (since the original
>> program has UB). But you cannot assert !overlap(p0, p1) in the well
>> defined program I mentioned earlier.
>
>
> Yea.. tricky...
> Well, if we combine this kind of checking with asan your particular problem
> is gone (because asan has quarantine for free-d memory and it won't be
> reused immediately)
I'm not sure if the problem is *gone* (since IIUC ASan will eventually
re-use the memory), but yes it will happen less often.
-- Sanjoy
>
>
>>
>>
>> -- Sanjoy
>>
>> >
>> >
>> >
>> > >
>> > > > > The same problem exists with constant addresses. LLVM states that
>> > > > > constant locations are noalias with themselves, and you again have
>> > > > > the
>> > > > > "noalias does not imply pointer inequality" problem.
>> > > >
>> > > > That won't even have to be special cased, because if we emit a check
>> > > > ConstPtr != ConstPtr,
>> > > > such a check will be trivially optimized away.
>> > >
>> > > But won't it be constant folded to trigger the sanitizer crash /
>> > > warning? That is, since LLVM will state the ConstPtr NoAlias
>> > > ConstPtr, you'll emit the check:
>> > >
>> > > if (overlap(ConstPtr, Sz, ConstPtr, Sz))
>> > > abort();
>> > >
>> > > which will get constant folded to
>> > >
>> > > if (true) abort();
>> > >
>> >
>> > ah, yes, you are right, then this will have to be special-cased.
>> >
>> >
>> > >
>> > > If you meant that the implementation of overlap will differ based on
>> > > whether the pointers are constant pointers or not, I'm not sure if
>> > > that will work, since the fact that the values whose aliasness (I
>> > > think I invented a new word :P ) you're checking could have been
>> > > arbitrarily obscured (AA could have looked through PHIs and selects
>> > > etc.) which will prevent you from rediscovering that the values were
>> > > constant pointers in some cases.
>> > >
>> > > -- Sanjoy
>> > >
>> >
>
>
More information about the llvm-dev
mailing list