[LLVMdev] IR extension proposal: bitset constants

[Jim Grosbach]

> On Jan 29, 2015, at 7:35 PM, Peter Collingbourne <peter at pcc.me.uk> wrote:
> 
> On Thu, Jan 29, 2015 at 06:51:51PM -0800, Jim Grosbach wrote:
>> Hi Peter,
>> 
>> Please forgive if this is an obvious question, but how reasonable is it for this approach to work when not all translation units are available to be rebuilt with the new information?
>> 
>> I'm very interested in what you're proposing here.
> 
> This technique works best if we can lay out the vtables in a specific order,
> but this is not necessarily a requirement. I can imagine an extension of the
> design where if the pointer is out of range we can fall back to a slow path
> that compares the vtable pointer against each element of a list of valid
> addresses that belong to external code.
> 
> The hard requirements (I believe) are that we have headers for all external
> classes that may interact with our code, and that the external objects export
> the needed vtable symbols. With those, we should be able to use Clang to
> build the list of valid addresses. I believe this should work with some
> implementations of the standard library, for example.

Oof. That’s a deal breaker for any of the uses I was hoping for. Nuts. :(

> 
> If the external library does not have all headers available, or (say) if
> it exposes classes defined in an anonymous namespace, we may not be able
> to identify all the valid addresses. To handle those cases we may need to
> develop some kind of blacklisting mechanism.
> 
> Thanks,
> -- 
> Peter