search for: function_ptrs

Dear LLVM, Recently I incorporated code into my project such that function pointers were supported, however it seems that the TarjanSCC_iterator no longer works on the call graph... main() is no longer reached while the function pointers are... I can provide code, but I have a feeling there is a simple fix... Has anyone gone through this? Thanks, Dave

> Recently I incorporated code into my project such that function pointers > were supported, however it seems that the TarjanSCC_iterator no longer > works on the call graph... main() is no longer reached while the function > pointers are... I can provide code, but I have a feeling there is a > simple fix... Has anyone gone through this? I'll need some more details before I

> if you take the time to print out the function each non-looping node iter > traverses, it never reaches main... Ok, first note that the CallGraph class does really stupid (but correct) things for function pointers, so you're not going to see anything remarkably nice here... Make sure to read the CallGraph.h comments to understand exactly what is going on. Despite that, I can verify

Thanks, I've been through the documentation, and if I visit main, i think everything will turn out correctly... Printing out the Call graph reveals that main is calling this external node i think you are making reference to. Could this be the problem? Dave On Fri, 6 Dec 2002, Chris Lattner wrote: > > if you take the time to print out the function each non-looping node iter >

Test Cases: (attached) Iteration code: (...) typedef TarjanSCC_iterator<CallGraph*> MyTarjan; CallGraph& callGraph = getAnalysis<CallGraph>(); MyTarjan iter = tarj_begin(&callGraph); MyTarjan end = tarj_end(&callGraph); while(iter!=end) iter++; (...) if you take the time to print out the function each non-looping node iter traverses, it never reaches main...

On Wed, Jul 17, 2013 at 9:06 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > To maintain the semantics of ordinary function calls, the prefix data > must have a particular format. Specifically, it must begin with a > sequence of bytes which decode to a sequence of machine instructions, > valid for the module's target, which transfer control to the point >

...c 2002, Vikram Adve wrote: > P.S. I have also updated the CSIL tree. Just check out > TarjanSCCIterator.h. > > --Vikram > http://www.cs.uiuc.edu/~vadve > > > > From: David Crowe <dcrowe at tremor.crhc.uiuc.edu> > > Subject: [LLVMbugs] Re: [LLVMdev] Tarjan+function_ptrs == trouble ? > > Sender: llvmbugs-admin at cs.uiuc.edu > > Date: Fri, 6 Dec 2002 00:54:41 -0600 (CST) > > > > Thanks, > > > > I've been through the documentation, and if I visit main, i think > > everything will turn out correctly... Printing out th...

As much as I like this idea for it's use in languages with type systems like Haskell and Scheme, this proposal would limit LLVM to non-Harvard architectures. That's generally a really small minority of all processors, but it would mean there could never be a clang-avr. An alternative you could use is, instead of using the function pointer as the variable where you are referring to a

Hi, I would like to propose that we introduce a mechanism in IR to allow arbitrary data to be stashed before a function body. The purpose of this would be to allow additional data about a function to be looked up via a function pointer. Two use cases come to mind: 1) We'd like to be able to use UBSan to check that the type of the function pointer of an indirect function call matches the