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. To
make things a little more accurate, you could scan the uses of any
function for which hasAddressTaken() returns true and see if any of its
uses escapes its function or escapes into memory or external code. I
believe hasAddressTaken() returns true if the function is subjected to a
cast instruction, and functions are often casted if they are used in a
call that uses a different signature than the function's declared signature.
To get anything more accurate, you'll need to use alias analysis or
points-to analysis. DSA tracks function pointers in the heap and can
tell you whether the function is called from external code. However,
DSA's accuracy currently suffers if it is run after LLVM's
optimizations, and the code needs some serious TLC.
Regards,
John Criswell
>
> On Tue, Dec 22, 2015 at 5:11 AM, Russell Wallace
> <russell.wallace at gmail.com <mailto:russell.wallace at gmail.com>> wrote:
>
> I need to track down all pointers anywhere in a module that could
> be pointing to functions (because some of the optimizations I want
> to do, require either identifying every use of a function, or
> conservatively identifying when such cannot be done).
>
> A starting point is to look at all the global variables:
>
> for (auto &G : M.globals())
> for (auto &V : G.operands())
> if (auto F = dyn_cast<Function>(V))
>
> Of course, instructions can also refer to functions, both as
> direct calls and otherwise:
>
> for (auto &F : M) {
> for (auto &I : inst_range(F)) {
> for (auto &V : I.operands())
> if (auto F = dyn_cast<Function>(V))
>
> But there are other things as well, for example it seems there is
> something called a personality function that can be a pointer to
> another function, so need to add that
>
> if (F.hasPersonalityFn())
>
> It seems there are other things called prefix data and prologue
> data, which are pointers to constants, which could contain
> pointers to functions, so would need to include those as well.
>
> Am I correct in thinking that prefix data and prologue data will
> not be included in the global variables list, so do need special
> handling?
>
> Could they be recursive? That is, could those constants contain
> pointers to other constants... which end up containing pointers to
> functions... such that none of the intermediate constant objects
> are in the global variable list?
>
> Is there anything else I'm missing?
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
--
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/20151222/c3de204d/attachment.html>