Displaying 20 results from an estimated 100 matches for "__thread".
2015 Jun 03
3
[LLVMdev] [lld] TBSS wrong size
Hi,
Yes, ldd is generating wrong tbss size. It is just considering one tbss section
and not calculating all sections from all objects. The following example on
x86_64 shows the issue:
--- t0.c ---
#include <stdio.h>
extern __thread int t0;
extern __thread int t1;
extern __thread int t2;
extern __thread int t3;
__thread int t4;
__thread int t5;
__thread int t6;
__thread int t7;
int main ()
{
t4 = 1;
t5 = 2;
t6 = 3;
t7 = 4;
printf ("%i %i %i %i\n", t0, t1, t2, t3);
printf ("%i %i %i %i\n", t4,...
2015 Jun 02
2
[LLVMdev] [lld] TBSS wrong size
Hi,
I am tracking some TLS issues with lld and found that it is
generating wrong tbss size for case where multiple modules
have non initialized threads variables. For instance:
-- t0.c --
__thread int x0;
__thread int x1;
__thread int x2;
extern __thread int e0;
extern __thread int e1;
extern __thread int e2;
extern __thread int e3;
int foo0 ()
{
return x0;
}
int main ()
{
return x0;
}
-- t1.c --
__thread int e0;
__thread int e1;
__thread int e2;
__thread int e3;
---
lld is genera...
2014 Jun 25
8
[LLVMdev] Cygwin bootstrap is incompatible with <mutex> (and most other threading C++11 libraries)
...t it actually has little to do with the multithreading
decisions.
LLVM is rapidly moving to use more C++11 library features and more
multithreading features. I think this is a good thing. However, we're
hitting a specific issue on cygwin when bootstrapping: Clang doesn't
support the Cygwin __thread implementation (it's different... sadly...). As
a consequence, a *huge* amount of libstdc++'s multithreading primitives
when bootstrapping, including <mutex>.
I don't think the current situation is tenable -- we really shouldn't be
increasingly using C++11 in LLVM while tryin...
2010 Nov 09
2
[LLVMdev] problem with __thread on linux/x86_64
Hi,
On Ubuntu Linux/x86_64, I get:
$ cat t.c
#include <stdio.h>
__thread int i = 7;
int main() { printf("%d\n", i); }
$ clang -o t t.c
$ ./t
Segmentation fault
(gdb) disas
Dump of assembler code for function main:
0x0000000000400560 <+0>: push %rbp
0x0000000000400561 <+1>: mov %rsp,%rbp
0x0000000000400564 <+4>: sub $0x10,%rs...
2010 Nov 11
0
[LLVMdev] problem with __thread on linux/x86_64
On 9 November 2010 16:42, Jay Foad <jay.foad at gmail.com> wrote:
> Hi,
>
> On Ubuntu Linux/x86_64, I get:
>
> $ cat t.c
> #include <stdio.h>
> __thread int i = 7;
> int main() { printf("%d\n", i); }
> $ clang -o t t.c
> $ ./t
> Segmentation fault
>
> (gdb) disas
> Dump of assembler code for function main:
> 0x0000000000400560 <+0>: push %rbp
> 0x0000000000400561 <+1>: mov %rsp,%rbp...
2010 Nov 11
2
[LLVMdev] problem with __thread on linux/x86_64
On 11 November 2010 12:49, Jay Foad <jay.foad at gmail.com> wrote:
> Delving a bit deeper, the difference seems to be that symbol "i" in
> the assembler source:
>
> .type i, at object # @i
> .section .tdata,"awT", at progbits
> .globl i
> .align 4
> i:
> .long 7
2010 Nov 11
0
[LLVMdev] problem with __thread on linux/x86_64
On 11 November 2010 13:22, Jay Foad <jay.foad at gmail.com> wrote:
> On 11 November 2010 12:49, Jay Foad <jay.foad at gmail.com> wrote:
>> Delving a bit deeper, the difference seems to be that symbol "i" in
>> the assembler source:
>>
>> .type i, at object # @i
>> .section .tdata,"awT", at
2010 Nov 11
1
[LLVMdev] problem with __thread on linux/x86_64
> I still think clang's assembler needs to do something like this, if it
> wants to be able to assembler .s files generated by GCC.
Working on it.
> Jay.
Cheers,
Rafael
2012 Jul 04
1
[LLVMdev] About thread_local in 3.0
Hi LLVM,
I am using 3.0, and I have a question about the __thread in c and
thread_local in LLVM IR: O1-O4 and the final linked code behave
differently.
////////////////////////////////////
The following C code is from the LLVM testcase
(SingleSource/UnitTests/Threads/2010-12-08-tls.c)
#include <stdio.h>
__thread int a = 4;
int foo (void)
{
return a;
}...
2016 May 03
4
Linux/ARM: Segfault issue when we build clang sources including __thread variable using -O2 flag
...d of -O0 flag, I could
not run the application normally by getting always the segmentation fault.
Here is debugging information with GDB command in case of that. As you can
see, we could not execute simple hello!! console application
because of the bug of clang/LLVM when we try to use "static __thread"
variable with -O2 flag.
*root:/dotnet/runtime.release.20160322.2/example> gdb ../corerun
./core.20160322*
GNU gdb (GDB) 7.9.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you ar...
2012 May 08
0
[LLVMdev] Address space information dropped
...ections imply different address spaces ?
> I rather wanted to have a special asm directive on the top of
> section definitions to switch between memories following an
> identical section layout for both of them.
Let's take a step back. "address space" is a type modifier like __thread.
>From codegen perspective, primarily changes the way access is done.
Variable declaration requires obtaining some pointer value and possibly
initialising it. For __thread, this is done by putting the object into
.tdata or .tbss sections and letting the linker do the rest. That is:
- merging cor...
2012 May 07
2
[LLVMdev] Address space information dropped
Le 07/05/2012 17:15, Joerg Sonnenberger a écrit :
> On Mon, May 07, 2012 at 05:15:59PM +0200, Ivan Llopard wrote:
>> Thanks for your quick response Joerg.
>>
>> We have a very small test case where there is global array and its
>> address space attribute specified like in the following code
>>
>> const int __attribute__((address_space(256))) fangle[13] =
2015 Aug 18
5
TSAN hack on AArch64 for Android
...is crippled in ways that no other system I know gets close.
> Layers upon layers of libraries, aliases, asm hackery, just to make it
> build. Adding Clang to the list of compilers did not make it better.
>
> This comment baffles me: "Ideally, this should be supported with the
> __thread keyword, but that is not yet supported, and it is a much
> bigger chunk of work to get it integrated into the default android
> cross compiler."
>
> AFAIK, __thread is supported by GCC and Clang, and this seems to be a
> problem in Android's linker. So, to work around a prob...
2015 Aug 18
2
TSAN hack on AArch64 for Android
...; we're going to consciously make TSAN *limp along* for the foreseeable
>> future? Is that a wise price to pay for such a far fetched goal?
>>
>> The "proper" solution seems to be to fix TLS support, which:
>> * "Ideally, this should be supported with the __thread keyword, but
>> that is not yet supported, and it is a much bigger chunk of work to
>> get it integrated into the default android cross compiler."
>>
>> So, to avoid a larger amount of work on another compiler, we're going
>> to cripple LLVM?
>>
>>...
2008 Feb 06
1
[LLVMdev] Advice on implementing fast per-thread data
...ormal thread-local storage scares me, because I don't know the
>> performance implications.
>
> You should read up about it then. :)
> Start here: http://people.redhat.com/drepper/tls.pdf
>
Thank you. You've just made my life about 3000% easier. Somehow I've
missed __thread- I was thinking of the clunky POSIX threads
implementation.
Playing around a little bit with this, I find that:
static __thread int i;
int foo(void) {
i += 1;
return i;
}
compiles to:
foo:
pushl %ebp
movl %esp, %ebp
movl %gs:i at NTPOFF, %eax
addl...
2017 Nov 08
2
[RFC] lld: Dropping TLS relaxations in favor of TLSDESC
On Tue, Nov 7, 2017 at 6:59 PM, Rafael Avila de Espindola <
rafael.espindola at gmail.com> wrote:
> Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> writes:
>
> > tl;dr: TLSDESC have solved most problems in formerly inefficient TLS
> access
> > models, so I think we can drop TLS relaxation support from lld.
> >
> > lld's code to handle
2011 Dec 06
0
[LLVMdev] Implement implicit TLS on Windows - need advice
...help.
>
> Kai
Thanks for working on this!
The first patch looks fine except that it's emitting to .tls when it
should be .tls$. Also, you need to add tests.
As for the second patch, that's not how MSVC 2010 emits code (and it
needs tests).
thread_local.c:
#ifdef _MSC_VER
#define __thread __declspec(thread)
#endif
__thread int i = 0;
int foo() {
return i++;
}
thread_local.asm:
PUBLIC _i
_TLS SEGMENT
_i DD 00H
_TLS ENDS
PUBLIC _foo
EXTRN __tls_array:DWORD
EXTRN __tls_index:DWORD
; Function compile flags: /Ogtpy
_TEXT SEGMENT
_foo PROC
; File c:\users\mspencer\projects\llvm-proje...
2019 Dec 10
2
aarch64 do not generate debug info for tls var
Hi Devs,
consider below testcase
$cat test.c
__thread int mtls=1;
void foo(){
mtls++;
}
it emits this debug info for mtls
0x0000002a: DW_TAG_variable
DW_AT_name ("mtls")
DW_AT_type (0x00000035 "int")
DW_AT_external (true)
DW_AT_decl_file ("test.c&qu...
2011 Dec 04
3
[LLVMdev] Implement implicit TLS on Windows - need advice
Hi!
LLVM currently does not implement the implicit TLS model on Windows.
This model is easy:
- a thread local variable ends up in the .tls section
- to access a thread local variable, you have to do
(1) load pointer to thread local storage from TEB
On x86_64, this is gs:0x58, on x86 it is fs:0x2C.
(2) load pointer to thread local state. In general, the index is
stored in variable
2010 May 13
0
[LLVMdev] Handling of thread_local globals by llc -march=cpp
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 = "i...