similar to: [LLVMdev] Advice on implementing fast per-thread data

On Mon, 4 Feb 2008, Brian Hurt wrote: > Another possibility, and I'm not sure how to do this in LLVM, would be to > sacrifice a register to hold the pointer to the unique per-thread > structure. This would be worthwhile to me even on the register-starved > x86-32. I suppose I could also just add a "hidden" (compiler-added and > -maintained) argument to every function

On Tue, 5 Feb 2008, Chris Lattner wrote: > On Mon, 4 Feb 2008, Brian Hurt wrote: >> Another possibility, and I'm not sure how to do this in LLVM, would be to >> sacrifice a register to hold the pointer to the unique per-thread >> structure. This would be worthwhile to me even on the register-starved >> x86-32. I suppose I could also just add a "hidden"

On Tue, Jun 12, 2012 at 7:53 PM, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: >> We're trying to figure out if there's a good reason for this, and if >> we want to mimic that behaviour in LLVM, or if we should just take the >> tls_model attribute as a starting point, and choose a better model if >> we can. > > On i386, non-PIC code can be used

On Jul 7, 2010, at 4:52 AM, Patrick Marlier wrote: > Which one is correct ? > - movl $tm_nest_level at TPOFF, %ecx > or > - movq $tm_nest_level at TPOFF, %rcx > or > - movl tm_nest_level at TPOFF, %ecx > I believe this is initial exec and so from: http://people.redhat.com/drepper/tls.pdf it would be movl tm_nest_level at TPOFF, %ecx > Otherwise, Is there a

> Right, that's a good point. > > On i386 Linux, the following code, > >  static __thread int x[100000]; >  int* get_x() { return x; } > > compiled with "clang -shared a.c -o a.so" won't be possible do dlopen. I get exactly the same result with gcc 4.7 with and without -ftls-model=global-dynamic: movq %gs:0, %eax addl $x at ntpoff, %eax > Rafael, I

Hi All, I'm working on various cleanups and simplifications to the asmprinters. One thing that is driving me nuts is that the asmprinters currently "reverse engineer" a lot of information when printing an operand that isel had when it created it. I'm specifically talking about all the suffixes generated by isel, like $non_lazy_ptr, @TLSGD, @NTPOFF, (%rip) etc. These

On Jul 7, 2010, at 11:20 AM, Eric Christopher wrote: > > On Jul 7, 2010, at 4:52 AM, Patrick Marlier wrote: > >> Which one is correct ? >> - movl $tm_nest_level at TPOFF, %ecx >> or >> - movq $tm_nest_level at TPOFF, %rcx >> or >> - movl tm_nest_level at TPOFF, %ecx >> > > I believe this is initial exec and so from: > >

On 06/22/2010 11:11 AM, Patrick Marlier wrote: > On 06/21/2010 08:21 PM, Eric Christopher wrote: >> On Jun 21, 2010, at 2:56 AM, Patrick Marlier wrote: >> >> >>> Hello, >>> >>> This bug affects all LLVM versions from 2.6 to trunk : >>> http://llvm.org/bugs/show_bug.cgi?id=5081 >>> >>> The workaround I found is to

On 06/21/2010 08:21 PM, Eric Christopher wrote: > On Jun 21, 2010, at 2:56 AM, Patrick Marlier wrote: > > >> Hello, >> >> This bug affects all LLVM versions from 2.6 to trunk : >> http://llvm.org/bugs/show_bug.cgi?id=5081 >> >> The workaround I found is to add this : >> >> Index: lib/Target/X86/X86Instr64bit.td >>

On Tue, 12 May 1998, Andi Kleen wrote on BUGTRAQ: > I assumed the libc would ignore NLSPATH when the app runs suid (similar > like it does with LD_LIBRARY_PATH etc.). If it doesn''t that is a bad bug. > > [... clickety click ... ] > > At least glibc 2.1 uses __secure_getenv() for NLSPATH. Don''t know about 2.0, > separate GNU gettext, or libc5. I have

On Fri, 8 Sep 2006, [UTF-8] Rafael Esp?ndola wrote: > I am not sure if it is the correct solution, but the attached patch > fixes the problem. Your solution is correct, in that it will work and follows with the current ifdef approach. I applied this patch though, which doesn't use the ifdefs, hopefully it is more robust:

All, Please excuse any ignorance in this e-mail as I am not a RH/CentOS/Fedora user and may blunder my way through the correct terminology for my request. I'm tasked with reconstructing the CentOS version of the GlibC library for testing with gethostbyname(). My mission is to show that we are not affected by the latest exploit for the product we are shipping targeted for RHEL and CentOS.

Hi all, I would like to hear your thoughts on adding support for extending the IR to allow for explicitly selecting which model to use for thread-local storage of a variable. The motivation is to allow Clang to support the "tls_model" variable attribute [1], as requested in PR9788. The idea would be to extend the IR to allow an optional TLS-model argument to the thread_local

I'm building R 2.13.1 on i686-pc-linux-gnu, using gcc 4.6.1 and with glibc 2.14. I get this error: In file included from xdr.c:61:0: ./rpc/types.h:63:14: error: conflicting types for 'malloc' make[4]: *** [xdr.o] Error 1 I can make the build proceed some by commenting out the declaration "extern char *malloc();" in xdr/rpc/types.h, but then I get a slew of other errors:

I'm building R 2.13.1 on i686-pc-linux-gnu, using gcc 4.6.1 and with glibc 2.14. I get this error: In file included from xdr.c:61:0: ./rpc/types.h:63:14: error: conflicting types for 'malloc' make[4]: *** [xdr.o] Error 1 I can make the build proceed some by commenting out the declaration "extern char *malloc();" in xdr/rpc/types.h, but then I get a slew of other errors:

Correcting my patch, reg. __thread stuff I'm not very familiar with. - D. 2012/12/1 Dmitry Mikushin <dmitry at kernelgen.org> > Agreed, done. > > One thing I'm not sure about is this statement in docs: > > POSIX.1-2008 marks *rand_r*() as obsolete. > > - And... what is the replacement? > > > 2012/12/1 Justin Holewinski <justin.holewinski at

> Please lemme know if it works. It does. Thanks. > I don't know what that is :( I believe that code compiled without -fpic is going into a DSO. This creates text relocations that are not supported on linux/amd64 (http://people.redhat.com/drepper/dsohowto.pdf). > -Chris Rafael

R-devel now makes use of gcc4's visibility features: for an in-depth account see http://people.redhat.com/drepper/dsohowto.pdf (and note there are older versions of that document around). Consider for example stats.so. On a gcc4 Linux system this has just three entry points gannet% nm -g stats.so | grep " T " 00002720 T R_init_stats 0004a544 T _fini 00001f28 T _init since the

http://bugzilla.mindrot.org/show_bug.cgi?id=536 stuge-openssh-unix-dev at cdy.org changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|no access to tty on Linux |no access to tty on Linux |2.0 |2.0 and 2.4+libc5 ------- Additional Comments

Agreed, done. One thing I'm not sure about is this statement in docs: POSIX.1-2008 marks *rand_r*() as obsolete. - And... what is the replacement? 2012/12/1 Justin Holewinski <justin.holewinski at gmail.com> > If we're keeping the state locally now, perhaps we should store it in a > per-thread variable. I know rand() isn't thread safe to begin with, but it > seems