Morten Ofstad
2004-Nov-10 11:10 UTC
[LLVMdev] LLVM and the "static initialization order fiasco"
Hello, I'm getting bitten by the "static initialization order fiasco" http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.12 The static data causing the problem is the static TypeMap<PointerValType, PointerType> PointerTypes; and other typemaps. The background is that in our product we are using an overridden new operator to track memory allocations. This system is intialized at the beginning of main(), and any 'new' before that will not be tracked. At the end of main any memory which has leaked is reported and after the end of main, any calls to 'delete' can only be deleting untracked memory. This is working well as long as you're careful with static objects, however the typemaps are intialized before main and the objects they contain are created in main (tracked) but destroyed after main together with the typemap. That means they end up being allocated by one memory system and freed by another which is obviously not a good thing. If there was some way for me to delete the types that have been constructed before main exits, that would solve the problem... Most other libraries have Init() and DeInit() functions instead of relying on static initialization -- I will make something like this myself as a temporary fix, but are there any opinions on a more long term solution? m.
Hello, I am a new user of LLVM and have been trying to find how Control Flow Graphs are implemented in it.I wish to get access to the internal structures of CFG and learn how LLVM makes them. Is there any existing tool that LLVM provides that makes CFG out of bytecode ? Thanks, Tanu --------------------------------- Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20041110/c52d0672/attachment.html>
Reid Spencer
2004-Nov-10 16:42 UTC
[LLVMdev] LLVM and the "static initialization order fiasco"
Hi Morten, I ran into this with XPS which carefully avoids static initialization and has its own operator new as well. However, there is little motivation in the LLVM team to fix this, and for good reason. Several of the feature of LLVM depend on static initialization but nothing in LLVM depends on the order. Most likely, you will have to do what I did: fix your operator new. It is not "standard" to have an operator new that is only available within the bounds of "main. You will need to override the various flavors of ::operator new and delete and ensure they are available both before and after "main". Others might have some more light on this subject. Reid. On Wed, 2004-11-10 at 03:10, Morten Ofstad wrote:> Hello, I'm getting bitten by the "static initialization order fiasco" > > http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.12 > > The static data causing the problem is the static > TypeMap<PointerValType, PointerType> PointerTypes; and other typemaps. > The background is that in our product we are using an overridden new > operator to track memory allocations. This system is intialized at the > beginning of main(), and any 'new' before that will not be tracked. At > the end of main any memory which has leaked is reported and after the > end of main, any calls to 'delete' can only be deleting untracked > memory. This is working well as long as you're careful with static > objects, however the typemaps are intialized before main and the objects > they contain are created in main (tracked) but destroyed after main > together with the typemap. That means they end up being allocated by one > memory system and freed by another which is obviously not a good thing. > > If there was some way for me to delete the types that have been > constructed before main exits, that would solve the problem... Most > other libraries have Init() and DeInit() functions instead of relying on > static initialization -- I will make something like this myself as a > temporary fix, but are there any opinions on a more long term solution? > > m. > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20041110/c9d0d87b/attachment.sig>
On Wed, Nov 10, 2004 at 06:39:12AM -0800, Tanu Sharma wrote:> I am a new user of LLVM and have been trying to find how Control Flow > Graphs are implemented in it.I wish to get access to the internal > structures of CFG and learn how LLVM makes them.LLVM does not need to construct a CFG, because the CFG is an explicit integral part of the program representation. Every BasicBlock ends with a terminator instruction, which is one of these: http://llvm.cs.uiuc.edu/docs/LangRef.html#terminators Each terminator has explicit target BasicBlocks (if any), which means you can navigate the CFG directly using the terminators or you can use the API pred_begin/end() and succ_begin/end() found in llvm/include/llvm/Support/CFG.h If you are not sure how to use them, search the code base for one of them to find example usage.> Is there any existing tool that LLVM provides that makes CFG out of > bytecode ?Above I described how to navigate the CFG within your compiler pass. If you mean "how can I visualize the CFG", then the answer is: $ analyze -print-cfg file.bc or $ analyze -print-cfg-only file.bc which will produce a 'dot' file. You will need to get 'dot' (search for graphviz package) which can convert .dot files into postscript. -- Misha Brukman :: http://misha.brukman.net :: http://llvm.cs.uiuc.edu
Apparently Analagous Threads
- [LLVMdev] Help : CFG in LLVM ( Implementation)
- [LLVMdev] LLVM and the "static initialization order fiasco"
- [LLVMdev] Randomizing Functions & Global variables
- [LLVMdev] Randomizing Functions & Global variables
- [LLVMdev] Randomizing Functions & Global variables