[llvm-dev] How to know the CallInst is a virtual call ?

[PenYiWang via llvm-dev]

I read some paper from NDSS and USENIX Security about  protecting C++
virtual calls.

So now I know maybe these paper implementation must modify front-end/Clang.



David Blaikie <dblaikie at gmail.com> 於 2020年6月19日 週五 上午2:16寫道：

> On Thu, Jun 18, 2020 at 10:52 AM PenYiWang <s89162504 at gmail.com> wrote:
> >
> > So if I want to know whether a CallInst is a C++ virtual call or not.
> >
> > I have to get the information at frontend/Clang.
> >
> > and then pass the information to middle-end/LLVM IR by myself.
> >
> > Is it right?
>
> Yes... but you maybe shouldn't be? What do you plan to do with that
> information?
>
> (not that there aren't/haven't been efforts to improve virtual call
> performance - I think there's something using ThinLTO to do a whole
> program analysis of virtual calls you could look into as examples of
> optimizations on virtual function calls)
>
> >
> > Thank you
> >
> >
> >
> > David Blaikie <dblaikie at gmail.com> 於 2020年6月19日 週五 上午1:26寫道：
> >>
> >> On Thu, Jun 18, 2020 at 9:53 AM PenYiWang via llvm-dev
> >> <llvm-dev at lists.llvm.org> wrote:
> >> >
> >> > Hi
> >> >
> >> > I know that a virtual call looks like this :
> >> >
> >> >   %4 = load %class.base*, %class.base** %1, align 8
> >> >   %5 = bitcast %class.base* %4 to void (%class.base*)***
> >> >   %6 = load void (%class.base*)**, void (%class.base*)*** %5, align 8
> >> >   %7 = getelementptr inbounds void (%class.base*)*, void
> (%class.base*)** %6, i64 0
> >> >   %8 = load void (%class.base*)*, void (%class.base*)** %7, align 8
> >> >   call void %8(%class.base* %4)
> >> >
> >> > There may be some action to get function pointer on vtable .
> >> >
> >> > But, when I scan a llvm ir file, if I just see a CallInst and it is
> an indirect call
> >> >
> >> > Is there any way to know whether the CallInst is a virtual call or
> not ?
> >>
> >> Not exactly, no - LLVM has no concept of virtual calls specifically -
> >> they are "just" indirect calls through a vtable. LLVM optimizations
> >> generally shouldn't be trying to reconstruct more high level semantics
> >> than exist in LLVM IR - an optimization to improve virtual function
> >> calls (using the existing IR - not accounting for some special cases
> >> that might involve adding extra metadata, etc) should be framed in
> >> terms of indirect calls in general (perhaps indirect calls from
> >> functions in constant arrays - maybe that's the specific subcase you
> >> want to target, etc).
> >>
> >> - Dave
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200619/5271a5d9/attachment.html>