[llvm-dev] Finding all pointers to functions

John Criswell via llvm-dev llvm-dev at lists.llvm.org
Mon Dec 28 08:32:01 PST 2015


On 12/28/15 9:50 AM, Christian Convey wrote:
>
>     On 12/22/15 4:45 AM, Russell Wallace via llvm-dev wrote:
>>     Oh, I just came across Function::hasAddressTaken. Maybe I can
>>     just use that instead?
>
>     You could conservatively assume that any function that has its
>     address taken has a pointer to it that escapes into memory or
>     external code.
>
>
> I wonder if a conservative estimate of pointed-to functions would also 
> need to include all functions with externally visible linkage?

This is correct.  Any function that is externally visible can be called 
be external code that is outside the analysis's scope; you must 
therefore treat it is a function that can be called by external code (in 
LLVM CallGraph parlance, it can be called by the external calling node).

If you're going to do this analysis, you want to do it in libLTO after 
the Internalize pass has been run.  The Internalize pass finds functions 
which are externally visible (because C linkage needs them to be in 
order for linking to work) and makes them internal since we know that we 
will not link with any more LLVM bitcode files.  You should get much 
better results that way.

As an FYI, DSA tracks this sort of information using the External (E) 
flag on the DSNode.   It can determine (provided it has sufficient 
precision) which heap objects are accessible to external code and which 
are not.

Regards,

John Criswell

>
> I could imagine a few routes by which that allows such a function to 
> have its address show up in the data being handled by the Module's own 
> code.


-- 
John Criswell
Assistant Professor
Department of Computer Science, University of Rochester
http://www.cs.rochester.edu/u/criswell

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151228/7e6590f5/attachment.html>


More information about the llvm-dev mailing list