[LLVMdev] IR extension proposal: bitset constants

[Pete Cooper]

Sent from my iPhone

> On Jan 31, 2015, at 4:43 PM, Peter Collingbourne <peter at pcc.me.uk> wrote:
> 
>> On Sat, Jan 31, 2015 at 02:53:40PM -0800, JF Bastien wrote:
>>>> 
>>>> The one think we need to ensure is that your metadata can be dropped by
>>> the
>>>> optimizer and the code remains correct. I'm guessing no vtable would mean
>>>> anything goes (not check)? That's bad security-wise, but it'll at least
>>>> work. We may want to make sure nothing gets dropped through a debug flag,
>>>> so that we can compile Chrome and be confident that all the checks we
>>> want
>>>> are there.
>>> 
>>> So the flag would determine whether no bitset present means return 1 or
>>> return 0? Sounds reasonable.
>> 
>> 
>> I'd keep it generating the same code, but have a debug output when the
>> debug flag is on. My reasoning is that this wouldn't happen if your feature
>> were a first-class IR construct, but because it's in the let's-try-it-out
>> metadata phase it needs to "just work" when metadata is dropped. Yours
>> being a security-oriented feature we'd want to be able to sanity-check that
>> things compiled as expected for users who care (like Chrome). Once the
>> feature graduates to IR instead of metadata it would be expected to always
>> be correct security-wise (never silently drop information).
> 
> Okay, makes sense.
> 
>> Or maybe I'm being overly cautious when it comes to metadata's ability to
>> be dropped?
> 
> As far as I am aware, only instruction-level metadata can be dropped entirely.
> Module-level metadata stays mostly intact, but references to globals in
> metadata can be replaced with nulls if the global is dropped.
> 
> The current behavior suits our purposes, but I can't find anywhere where any of
> this behavior is specified, and it's entirely possible that it may change. The
> flag that you propose would be a useful guard against that possibility.
I think too much would break if global named metadata just start being dropped. So for now at least it's fair to expect it's there.

For the global variables it would be fair to add them to the llvm.compiler.used list if you want to keep them around. Anyone opting in to the bitsets it likely ok with a few extra globals lasting until link time.

Thanks
Pete
> 
> Thanks,
> -- 
> Peter
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev