[cfe-dev] [LLVMdev] Adding CFI checks to clang vs llvm

Chandler Carruth chandlerc at google.com
Tue Feb 17 20:02:32 PST 2015


On Tue, Feb 17, 2015 at 7:43 PM, Peter Collingbourne <peter at pcc.me.uk>
wrote:

> > My primary concern is that I would very much like the CFI implementation
> to
> > be truly generic for indirect function calls rather than specific to type
> > hierarchies.
> >
> > Is the issue that for virtual calls there is a dramatically cheaper way
> to
> > structure the CFI implementation than there is for fully general indirect
> > calls?
>
> The main problem with a design that is fully generic to indirect calls
> is a lack of precision. If we design our checks independent of the type
> hierarchy we could permit virtual calls to a function of the wrong type if
> the parameter/return types would otherwise match. See also [1] which
> contains
> some discussion of precision.
>

This is helpful information, and clarifies a miscommunication. =]

My hope would be that we could implement the checks generically, but
provide constraints from the frontend to further constrain the correct
target set. Does that make sense at all?

Maybe to put it another way, if I have some other language than C++ which
provides a different language-based constraint on the set of possible
targets for an indirect call, it would be nice for both Clang and that
other language frontend to encode generic target constraints and then a
common check implementation to kick in to implement them. And then the
check mechanism could be *completely* generic in the case of fully general
indirect calls.


>
> There are also ancillary performance benefits of this design. For example,
> if we lay out the type information near the virtual tables we can in some
> cases avoid an additional cache miss.


That does seem quite nice to preserve if possible. Is it possible to use a
hint to get this?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150217/0d7d1c15/attachment.html>


More information about the cfe-dev mailing list