[PATCH] Annotate our UB to sneak it past the sanitizers

[Justin Bogner via llvm-commits]

Alexey Samsonov <vonosmas at gmail.com> writes:
> On Fri, Feb 26, 2016 at 2:56 PM, Justin Bogner <mail at justinbogner.com> wrote:
>> Alexey Samsonov <vonosmas at gmail.com> writes:
>>> What are the failures you observe? We're running an UBSan bootstrap on our
>>> buildbot, and it's usually green:
>>>
>> http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/11059
>>
>> Is that running without any blacklists?
>
> Hm, not really. cmake -DLLVM_USE_SANITIZER=Undefined expands to
> "-fsanitize=undefined -fno-sanitize=vptr,function",
> but this specific error seem to be coming from -fsanitize=object-size.
>
>> These are both the undefined
>> behaviour in ilist_node and how we use it, ie:
>>
>>   runtime error: downcast of address XXX with insufficient space for an object of type 'llvm::MachineBasicBlock'
>>
>> This is because "Sentinel" in both of these functions is an
>> ilist_half_node, which is certainly not large enough.
>>
>> It's certainly been necessary to blacklist MachineFunction on darwin
>> since at least October, though the bug existed and wasn't caught by
>> ubsan before that:
>>
>>   http://lists.llvm.org/pipermail/llvm-dev/2015-October/091115.html
>>
>> The one in MemorySSA just started hitting a month or so ago.
>>
>>> On Thu, Feb 25, 2016 at 2:42 PM, Kostya Serebryany <kcc at google.com> wrote:
>>>> Sounds very scary.
>>>> At the very least we should specify which flavor of UB we allow
>>>> here (not just all of it)
>>
>> The macro expands to no_sanitize("undefined") right now - does
>> no_sanitize take a more specific argument?
>>
>>> +1 I would prefer LLVM_NO_SANITIZE("kind") macro.
>>
>> Sure. I'll update the patch.
>
> Yes, you can use smth. like
>   __attribute__((no_sanitize("signed-integer-overflow")))

Here's an updated patch. This ones refers to the PR, renames the macro
LLVM_NO_SANITIZE() and calls it with "object-size" instead of
"undefined".

Optionally, I could annotate the 7 other cases of this UB that aren't
currently caught by running check-all under ubsan. I'm not sure which
way's better - thoughts?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ignore-ub-2.patch
Type: text/x-patch
Size: 2934 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160226/6a93c21a/attachment.bin>