llvm dev - May 2010 - [LLVMdev] Handling of thread_local globals by llc -march=cpp

target triple = "i386-pc-linux-gnu"

On 13/05/2010, at 9:25 PM, Anton Korobeynikov wrote:
>> int (*FP)() = (int (*)())FPtr;
>> int res = FP();
>> 
>> when the function executes correctly in the case of instead having
created a standard global variable.
> What is the platform you're running the code on?
> 
> -- 
> With best regards, Anton Korobeynikov
> Faculty of Mathematics and Mechanics, Saint Petersburg State University

I note also that this is not a currently unsupported target case where an error
should/could/would be produced on attempting to emit code with thread local
references. I say this because clang is able to compile both c source with
__thread on a global and bc containing a @variable = thread_local global ... and
a function that references the thread local global variable to both assembly and
machine code that has segment register offset addressing.

On 13/05/2010, at 9:26 PM, o.j.sivart at gmail.com wrote:
> target triple = "i386-pc-linux-gnu"
> 
> On 13/05/2010, at 9:25 PM, Anton Korobeynikov wrote:
> 
>>> int (*FP)() = (int (*)())FPtr;
>>> int res = FP();
>>> 
>>> when the function executes correctly in the case of instead having
created a standard global variable.
>> What is the platform you're running the code on?
>> 
>> -- 
>> With best regards, Anton Korobeynikov
>> Faculty of Mathematics and Mechanics, Saint Petersburg State University
>

> I note also that this is not a currently unsupported target case where an
error should/could/would be produced on attempting to emit code with thread
local references. I say this because clang is able to compile both c source with
__thread on a global and bc containing a @variable = thread_local global ... and
a function that references the thread local global variable to both assembly and
machine code that has segment register offset addressing.
Maybe TLS stuff is just broken inside JIT?

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

Hi all,

Following on from "Handling of thread_local globals by llc -march=cpp"
I thought I'd repost queries that lead on from this under a more appropriate
new title. My query now is does ExecutionEngine::getPointerToFunction(), and
related, support thread local global storage? Thread local storage is supported
by clang, both in bc generation (it produces thread_local syntax), assembly
generation (it produces segment register offset addressing), and machine code,
thus LLVM clearly has working support for thread local global storage. However
in the case of creating IR directly via calls into the LLVM api it appears that
ExecutionEngine::getPointerToFunction() and related may not handle functions
that reference thread local global storage. The reason I say this is captured in
the details of one of my previous emails which are as follows.

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.

On 14/05/2010, at 12:05 AM, o.j.sivart at gmail.com wrote:
> I note also that this is not a currently unsupported target case where an
error should/could/would be produced on attempting to emit code with thread
local references. I say this because clang is able to compile both c source with
__thread on a global and bc containing a @variable = thread_local global ... and
a function that references the thread local global variable to both assembly and
machine code that has segment register offset addressing.
> 
> On 13/05/2010, at 9:26 PM, o.j.sivart at gmail.com wrote:
> 
>> target triple = "i386-pc-linux-gnu"
>> 
>> On 13/05/2010, at 9:25 PM, Anton Korobeynikov wrote:
>> 
>>>> int (*FP)() = (int (*)())FPtr;
>>>> int res = FP();
>>>> 
>>>> when the function executes correctly in the case of instead
having created a standard global variable.
>>> What is the platform you're running the code on?
>>> 
>>> -- 
>>> With best regards, Anton Korobeynikov
>>> Faculty of Mathematics and Mechanics, Saint Petersburg State
University
>> 
>