[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