Hello, I'm getting bitten by the "static initialization order fiasco"
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?
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 ?
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
Others might have some more light on this subject.
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:
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
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
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
$ 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.