llvm dev - Nov 2004 - [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>

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