Re: support for __thread
On Wed, 24 Dec 2003, Alexander Kabaev wrote: Sorry for late response, but ... On Sun, 21 Dec 2003 17:31:03 -0500 (EST) Daniel Eischen [EMAIL PROTECTED] wrote: libkse is ready to add support for it but I believe there's some additional work to be done in rtld-elf first. libkse in current shape is unable to support GNU TLS model, which is what our system GCC is configured to use by default. While I can Right, I think we just need to add one more dereference if that is what you mean. certainly switch it to less optimal in some cases model defined by Please do :) Sun, I think maintaining binary compat in TLS are is an important feature given the fact that precompiled linux-only object files are getting more and more popular. Being binary compatible will give is at least a change to link Linux object file into native FreeBSD binary. We don't want to have a separate LDT for each thread in libkse; it adds overhead, limits number of threads, and isn't needed. Also, while you may be able to have binary compat for TLS, you will not for the rest of the threading system so any advantage in that regard is marginal. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: support for __thread
Alfred Perlstein wrote: Well yes, but first would be getting the toolchain to emit proper code... It'd help but the linker is where all the action happens.. Marcel seems to understand this quite well. I can give the ld.so work a shot if someone gives me a general idea of how to get at the linker sets and registers in C code. WHen you have read and understood the document that describes the __thread implementation then I guess the next step would be to read and understand ld (and the rt version). It would be nice if it worked with libc_r as well, is there any chance for that? Webstone doesn't need kernel threads really... the relatively lightweight nature of libc_r doing strictly network IO makes it an attractive solution for what I'm trying to accomplish. Once it has been done for libpthread then it is almost free for libc_r because in libc_r we can set %gx once and forget it and just change the address it points to whenever we schedule a different thread. -- ++ __ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ [EMAIL PROTECTED] +--x USA\ a very strange | ( OZ)\___ ___ | country ! +- X_.---._/presently in San Francisco \_/ \\ v ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: support for __thread
On Mon, 22 Dec 2003, Dan Nelson wrote: In the last episode (Dec 22), Daniel Eischen said: I'd like to stay away from maintaining libc_r any further; not that it can't be done, but with libkse and libthr around, why? Do gdb and pstack (in ports) handle libkse or libthr threads? libc_r I don't know what pstack is, but we should have gdb for 5.3R. is a great debugging tool, if nothing else. I can't even attach to a libkse-threaded program with gdb; the tracee gets SIGSTOP'ped, and gdb just sits there. You have to kill -9 gdb from another tty, and the tracee dies. gdb can attach to a libc_r program, view all the threads, and detach without affecting the tracee. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: support for __thread
On Sun, 21 Dec 2003, Alfred Perlstein wrote: Any idea of how much effort it would take? I have no clue as to how to fix our toolchain, gooing the work in ld.so doesn't see that awful, but it's not trivial either: http://people.freebsd.org/~alfred/tls.pdf I want a threaded webstone so that I can generate a lot more load with wimpier client boxes on FreeBSD. While you're working on gcc / our linker, you may want to investigate this article that I just saw on news.google.com as well: --- GCC summit in Kuwait concludes meetings, approves ''anti-terrorism'' agreement --- I'm not sure exactly what OS support that requires, but having it would certainly put us ahead of OpenBSD's ProPolice + nonexec stack! Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
support for __thread
How do I get __thread to work for me? http://gcc.gnu.org/onlinedocs/gcc/Thread-Local.html it seems the assembler chokes on it? -- - Alfred Perlstein - Research Engineering Development Inc. - email: [EMAIL PROTECTED] cell: 408-480-4684 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: support for __thread
* Alfred Perlstein [EMAIL PROTECTED] [031221 02:47] wrote:
How do I get __thread to work for me?
http://gcc.gnu.org/onlinedocs/gcc/Thread-Local.html
it seems the assembler chokes on it?
Taking this code:
#include stdio.h
__thread int x;
int
main(int argc, char **argv)
{
printf(duh:\n);
return (0);
}
Running it through gcc -S results in an asm file that has this
at the end:
.globl %lx
.section.tbss,awT,@nobits
.p2align 2
.type %lx, @object
.size %lx, 4
%lx:
.zero 4
.ident GCC: (GNU) 3.3.3 [FreeBSD] 20031106
as(1) will accept this file if I replace all occurrances of
'%lx' with 'lx', it then appears to create special section
called tbss, (this is used for automatic thread specific
data).
Where is the bug, the compiler or the assembler, anyone have
a fix?
--
- Alfred Perlstein
- Research Engineering Development Inc.
- email: [EMAIL PROTECTED] cell: 408-480-4684
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: support for __thread
On Sun, 21 Dec 2003, Alfred Perlstein wrote: * Alfred Perlstein [EMAIL PROTECTED] [031221 02:47] wrote: How do I get __thread to work for me? http://gcc.gnu.org/onlinedocs/gcc/Thread-Local.html it seems the assembler chokes on it? We don't have support for it yet. Why do you want it? -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: support for __thread
* Daniel Eischen [EMAIL PROTECTED] [031221 12:08] wrote: On Sun, 21 Dec 2003, Alfred Perlstein wrote: * Alfred Perlstein [EMAIL PROTECTED] [031221 02:47] wrote: How do I get __thread to work for me? http://gcc.gnu.org/onlinedocs/gcc/Thread-Local.html it seems the assembler chokes on it? We don't have support for it yet. Why do you want it? .) it'd be nice to have it for future work .) linux seems to have it, so does MS but mostly: I'm porting webstone to use threads, and it uses that construct for the win32 threaded portion, it'd be really nice if we supported it so that I could make use of it instead of changing hundreds of lines of code. Any idea of how much effort it would take? I have no clue as to how to fix our toolchain, gooing the work in ld.so doesn't see that awful, but it's not trivial either: http://people.freebsd.org/~alfred/tls.pdf I want a threaded webstone so that I can generate a lot more load with wimpier client boxes on FreeBSD. Right now doing hundreds of connections nearly kills my desktop, but when threaded it barely hiccups. Also, in re: thread things: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/60477 :( -- - Alfred Perlstein - Research Engineering Development Inc. - email: [EMAIL PROTECTED] cell: 408-480-4684 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: support for __thread
On Sun, 2003-12-21 at 12:08, Daniel Eischen wrote: On Sun, 21 Dec 2003, Alfred Perlstein wrote: * Alfred Perlstein [EMAIL PROTECTED] [031221 02:47] wrote: How do I get __thread to work for me? http://gcc.gnu.org/onlinedocs/gcc/Thread-Local.html it seems the assembler chokes on it? We don't have support for it yet. Why do you want it? From what I understand, having thread-local variables would be a big bonus for OpenGL. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: support for __thread
On Sun, 21 Dec 2003, Alfred Perlstein wrote: * Daniel Eischen [EMAIL PROTECTED] [031221 12:08] wrote: On Sun, 21 Dec 2003, Alfred Perlstein wrote: * Alfred Perlstein [EMAIL PROTECTED] [031221 02:47] wrote: How do I get __thread to work for me? http://gcc.gnu.org/onlinedocs/gcc/Thread-Local.html it seems the assembler chokes on it? We don't have support for it yet. Why do you want it? .) it'd be nice to have it for future work .) linux seems to have it, so does MS libkse is ready to add support for it but I believe there's some additional work to be done in rtld-elf first. but mostly: I'm porting webstone to use threads, and it uses that construct for the win32 threaded portion, it'd be really nice if we supported it so that I could make use of it instead of changing hundreds of lines of code. I would discourage using __thread and instead make the API better so it's not needed. My fear is that once we have it, it'll be abused in all sorts of ways. I can understand needing it for something like nvidia's OpenGL where you have an existing API layered over their drivers and they need to get thread-local-storage very often (tight loops). Any idea of how much effort it would take? I have no clue as to how to fix our toolchain, gooing the work in ld.so doesn't see that awful, but it's not trivial either: http://people.freebsd.org/~alfred/tls.pdf Yes, we've been over that in either -current or -threads; I forget which. I think libkse already obeys the tls spec WRT %gs; we just need some hooks/coordination into/with rtld. I want a threaded webstone so that I can generate a lot more load with wimpier client boxes on FreeBSD. Right now doing hundreds of connections nearly kills my desktop, but when threaded it barely hiccups. There is always pthread_[gs]pecific which is what normally should be used. Also, in re: thread things: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/60477 :( There were some thoughts on restructuring our name lookups so that they would be thread-safe. I would rather see that than littering __thread around libc. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: support for __thread
* Daniel Eischen [EMAIL PROTECTED] [031221 14:31] wrote: On Sun, 21 Dec 2003, Alfred Perlstein wrote: * Daniel Eischen [EMAIL PROTECTED] [031221 12:08] wrote: On Sun, 21 Dec 2003, Alfred Perlstein wrote: * Alfred Perlstein [EMAIL PROTECTED] [031221 02:47] wrote: How do I get __thread to work for me? http://gcc.gnu.org/onlinedocs/gcc/Thread-Local.html it seems the assembler chokes on it? We don't have support for it yet. Why do you want it? .) it'd be nice to have it for future work .) linux seems to have it, so does MS libkse is ready to add support for it but I believe there's some additional work to be done in rtld-elf first. Well yes, but first would be getting the toolchain to emit proper code... Redhat Linux's gcc 3.2.2 will output: .globl x .section.tbss,awT,@nobits .align 4 .type x,@object .size x,4 x: .zero 4 .ident GCC: (GNU) 3.2.2 20030222 (Red Hat Linux 3.2.2-5) ours: .globl %lx .section.tbss,awT,@nobits .p2align 2 .type %lx, @object .size %lx, 4 %lx: .zero 4 .ident GCC: (GNU) 3.3.3 [FreeBSD] 20031106 It looks like a simple typo or format string error of some kind, but I have no clue where this is done in gcc, what would take me hours could likely been in a couple of minutes if the right people *kicks obrien* would respond. :) but mostly: I'm porting webstone to use threads, and it uses that construct for the win32 threaded portion, it'd be really nice if we supported it so that I could make use of it instead of changing hundreds of lines of code. I would discourage using __thread and instead make the API better so it's not needed. My fear is that once we have it, it'll be abused in all sorts of ways. I can understand needing it for something like nvidia's OpenGL where you have an existing API layered over their drivers and they need to get thread-local-storage very often (tight loops). Well, this allows the port to be pretty seamless, with minimal chances for bugs... I've already had a lot of issues porting the code because of other distractions. I figure that supporting it would be nice. I can give the ld.so work a shot if someone gives me a general idea of how to get at the linker sets and registers in C code. It would be nice if it worked with libc_r as well, is there any chance for that? Webstone doesn't need kernel threads really... the relatively lightweight nature of libc_r doing strictly network IO makes it an attractive solution for what I'm trying to accomplish. Any idea of how much effort it would take? I have no clue as to how to fix our toolchain, gooing the work in ld.so doesn't see that awful, but it's not trivial either: http://people.freebsd.org/~alfred/tls.pdf Yes, we've been over that in either -current or -threads; I forget which. I think libkse already obeys the tls spec WRT %gs; we just need some hooks/coordination into/with rtld. As I said, I may be able to do this, but I definetly have no clue how to fix the compiler. I want a threaded webstone so that I can generate a lot more load with wimpier client boxes on FreeBSD. Right now doing hundreds of connections nearly kills my desktop, but when threaded it barely hiccups. There is always pthread_[gs]pecific which is what normally should be used. That doesn't lend itself to a clean port. I'll need to extensively modify the source to do that, I can but was hoping that I could guilt people into getting on the bandwagon wrt __thread. :) Also, in re: thread things: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/60477 :( There were some thoughts on restructuring our name lookups so that they would be thread-safe. I would rather see that than littering __thread around libc. I actually don't have any intention of polluting libc with __thread. I was just whining about yet another issue (I actually hit it with webstone, but there's a workaround which is to make sure that the domain name resolves exactly to what you have in the config file, that avoids threaded name lookups.) I think I can actually fix our libc functions to use thread local storage if I ever get around to it. As long as threads copy the return value from gethostent/getservent and don't just hand the pointer to another thread they should be fine, although it would act funny if threads expected to be able to iterate through the hostent/servent files by having several threads call the functions expecting each to get alternating lines. Any thoughts on this? Supposedly the interfaces that make sense (the ones that use the host_data parameter) are depricated on some UNIX versions already, and honestly the glibC and Solaris ones are just STUPID. :( -- - Alfred Perlstein - Research Engineering Development Inc. - email: [EMAIL PROTECTED] cell: 408-480-4684
Re: support for __thread
On Sun, 21 Dec 2003, Alfred Perlstein wrote: * Daniel Eischen [EMAIL PROTECTED] [031221 14:31] wrote: On Sun, 21 Dec 2003, Alfred Perlstein wrote: * Daniel Eischen [EMAIL PROTECTED] [031221 12:08] wrote: On Sun, 21 Dec 2003, Alfred Perlstein wrote: * Alfred Perlstein [EMAIL PROTECTED] [031221 02:47] wrote: How do I get __thread to work for me? http://gcc.gnu.org/onlinedocs/gcc/Thread-Local.html it seems the assembler chokes on it? We don't have support for it yet. Why do you want it? .) it'd be nice to have it for future work .) linux seems to have it, so does MS libkse is ready to add support for it but I believe there's some additional work to be done in rtld-elf first. Well yes, but first would be getting the toolchain to emit proper code... [...] It looks like a simple typo or format string error of some kind, but I have no clue where this is done in gcc, what would take me hours could likely been in a couple of minutes if the right people *kicks obrien* would respond. :) Try kan. but mostly: I'm porting webstone to use threads, and it uses that construct for the win32 threaded portion, it'd be really nice if we supported it so that I could make use of it instead of changing hundreds of lines of code. I would discourage using __thread and instead make the API better so it's not needed. My fear is that once we have it, it'll be abused in all sorts of ways. I can understand needing it for something like nvidia's OpenGL where you have an existing API layered over their drivers and they need to get thread-local-storage very often (tight loops). Well, this allows the port to be pretty seamless, with minimal chances for bugs... I've already had a lot of issues porting the code because of other distractions. I figure that supporting it would be nice. Yes, for OpenGL/nvidia users mostly. webstone looks pretty simple to fix so it doesn't need __thread, and would benefit platforms other platforms. Which webstone are you using? The same version as in www/ports, or is there another more recent version out there that we haven't tracked yet. I can give the ld.so work a shot if someone gives me a general idea of how to get at the linker sets and registers in C code. Don't ask me :) It would be nice if it worked with libc_r as well, is there any chance for that? Webstone doesn't need kernel threads really... the relatively lightweight nature of libc_r doing strictly network IO makes it an attractive solution for what I'm trying to accomplish. I'd like to stay away from maintaining libc_r any further; not that it can't be done, but with libkse and libthr around, why? Any idea of how much effort it would take? I have no clue as to how to fix our toolchain, gooing the work in ld.so doesn't see that awful, but it's not trivial either: http://people.freebsd.org/~alfred/tls.pdf Yes, we've been over that in either -current or -threads; I forget which. I think libkse already obeys the tls spec WRT %gs; we just need some hooks/coordination into/with rtld. As I said, I may be able to do this, but I definetly have no clue how to fix the compiler. I want a threaded webstone so that I can generate a lot more load with wimpier client boxes on FreeBSD. Right now doing hundreds of connections nearly kills my desktop, but when threaded it barely hiccups. There is always pthread_[gs]pecific which is what normally should be used. That doesn't lend itself to a clean port. I looked at the port and it should be easy enough to fix it so that it does support threads without TLS. I'll need to extensively modify the source to do that, I can but was hoping that I could guilt people into getting on the bandwagon wrt __thread. :) Also, in re: thread things: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/60477 :( There were some thoughts on restructuring our name lookups so that they would be thread-safe. I would rather see that than littering __thread around libc. I actually don't have any intention of polluting libc with __thread. I was just whining about yet another issue (I actually hit it with webstone, but there's a workaround which is to make sure that the domain name resolves exactly to what you have in the config file, that avoids threaded name lookups.) I think I can actually fix our libc functions to use thread local storage if I ever get around to it. As long as threads copy the I'd rather see a thread-safe function(s) instead of using __thread. return value from gethostent/getservent and don't just hand the pointer to another thread they should be fine, although it would act funny if threads expected to be able to iterate through the hostent/servent files by having several threads call the functions expecting each to get alternating lines. Any thoughts on this? Supposedly the
Re: support for __thread
In the last episode (Dec 22), Daniel Eischen said: I'd like to stay away from maintaining libc_r any further; not that it can't be done, but with libkse and libthr around, why? Do gdb and pstack (in ports) handle libkse or libthr threads? libc_r is a great debugging tool, if nothing else. I can't even attach to a libkse-threaded program with gdb; the tracee gets SIGSTOP'ped, and gdb just sits there. You have to kill -9 gdb from another tty, and the tracee dies. gdb can attach to a libc_r program, view all the threads, and detach without affecting the tracee. -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
