[LLVMdev] Usage of getenv() inside LLVM and thread safety

Dirkjan Bussink d.bussink at gmail.com
Thu May 23 06:49:55 PDT 2013


In Rubinius we're seeing an occasional crash inside LLVM that always happens inside getenv(), which is used for example when creating a MCContext (inside lib/MC/MCContext.cpp, it checks getenv("AS_SECURE_LOG_FILE")).

The problem is that getenv() and friends aren't thread safe and Rubinius provides a multithreaded system. We can relatively easily get locking setup around the getenv() calls we do in Rubinius, but that's really complex to be able to do for LLVM. I also don't know what the guarantees are here that LLVM wants to provide regarding thread safety of code that happens to have a getenv() call inside it.

What would be the best approach to solving this? Would it be necessary to put locking around this inside our usage of LLVM? Should LLVM provide a locking mechanism for this or should there be a way to make the getenv() calls optional in the places there are used (like here in MCContext). 

Regarding the thread safety, this is what the open group says about getenv():

"The getenv() function need not be reentrant. A function that is not required to be reentrant is not required to be thread-safe."



Dirkjan Bussink

More information about the llvm-dev mailing list