[LLVMdev] Handling of thread_local globals by llc -march=cpp

[o.j.sivart at gmail.com]

Thanks for the quick reply and fix. Now it just means I have to hunt further in exploring why, in my simple test program, replacing the following line of code:

GlobalVariable* global = new GlobalVariable(*MyModule,
    IntegerType::get(getGlobalContext(), 32), false, GlobalValue::ExternalLinkage, 0, "global");

with the following line of code:

GlobalVariable* global = new GlobalVariable(*MyModule,
    IntegerType::get(getGlobalContext(), 32), false, GlobalValue::ExternalLinkage, 0, "global", 0, true);

in order to create a thread local global variable instead of a standard global variable causes the function (which uses the global) produced by the following line of code:

void *FPtr = MyExecutionEngine->getPointerToFunction(MyFunction);

to segfault when I call it in the following sequence of code:

int (*FP)() = (int (*)())FPtr;
int res = FP();

when the function executes correctly in the case of instead having created a standard global variable.

Doh!

As far as I got with this was to note that the machine code produced for the function is attempting to still do a move from a memory location (and an inaccessible one at that: 0xfffffffc) instead of doing a move from an offset from the segment register.

On 13/05/2010, at 5:13 PM, Anton Korobeynikov wrote:

> Hello
> 
>> I've been exploring thread local globals in llvm and as part of this investigation I ran llc -march=cpp over a trivial llvm bc file which uses thread local storage for a global. For some reason llc -march=cpp seems to ignore the thread_local and produce code to create a standard global. Is this expected behaviour, a known limitation, or otherwise?
> Thanks for the report. Should be fixed in r103702
> 
> -- 
> With best regards, Anton Korobeynikov
> Faculty of Mathematics and Mechanics, Saint Petersburg State University