[llvm-dev] Help needed: Recuperate return addresses of virtual and non virtual C++ functions with Clang and LLVM

Reid Kleckner via llvm-dev llvm-dev at lists.llvm.org
Tue Dec 13 09:54:21 PST 2016


At compile time, it is impossible to compute the actual addresses that will
appear at runtime in the program for many reasons. However, LLVM can
approximate the set of possible call sites that could call any given
virtual or non-virtual function. With this information you can build a call
graph. It sounds like that might be what you want, and that you'll make
better headway if you search for that.

My understanding is that without additional annotations, LLVM doesn't know
what call sites are calling which virtual methods. Control flow integrity
(CFI) adds annotations about this stuff.

On Tue, Dec 13, 2016 at 8:41 AM, Paul Muntean via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> I am working with this setup: LLVM+Clang Compiler on an Ubuntu 64bit OS.
>
> Questions:
>
> Is it  possible to get the return addresses of virtual function call
> and non virtual C++ methods inside Clang and LLVM.
>
> Is thre a way to get the candidate addresses where the return address
> points back after each function return was performed.
>
> I have a few questions and hopefully you guys can help me out.
>
> The return-addresses of indirect function calls to virtual functions
> (and thus v-tables), are they pointers?
>
> If not, what format do they have? How are those handled by Clang?
>
> Is the return address of a non virtual function in Clang a pointer or
> a hardcoded value?
>
> How can I get the return addresses of an indirect call to a virtual
> function using LLVM? Do i have to import them from Clang and make them
> available during LTO?
>
> Is thinLTO a better candidate for helping me recuperate this information?
>
> Does the return address of a function called from an indirect
> call-site always jump back to the next line (instruction) of assembly
> code after the callsite instruction. Are there some occurrences where
> it doesn't?
>
> How is this handled in Clang?
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161213/4e96bdcb/attachment.html>


More information about the llvm-dev mailing list