[LLVMdev] IR extension proposal: bitset constants

[Peter Collingbourne]

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.

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