This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: about TLS and GCC
- From: Nick Ing-Simmons <nick dot ing-simmons at elixent dot com>
- To: jakub at redhat dot com
- Cc: Jonathan Wilson <jonwil at tpgi dot com dot au>, gcc at gnu dot org
- Date: Mon, 20 Oct 2003 14:53:27 +0100
- Subject: Re: about TLS and GCC
- References: <3F93DEB8.50801@tpgi.com.au> <20031020112806.GI12344@sunsite.ms.mff.cuni.cz>
- Reply-to: Nick Ing-Simmons <nick dot ing-simmons at elixent dot com>
Jakub Jelinek <jakub@redhat.com> writes:
>I don't know how win32 handles dlopen (or whatever similar functionality it
>has)
When a DLL loaded/unloaded the entry point of the DLL is called
it has a signature like:
BOOL APIENTRY
DllEntryPoint(hInst, reason, reserved)
HINSTANCE hInst; /* Library instance handle. */
DWORD reason; /* Reason this function is being called. */
LPVOID reserved; /* Not used. */
{
...
}
Reason can be DLL_PROCESS_ATTACH, DLL_PROCESS_DETACH,
DLL_THREAD_ATTACH or DLL_THREAD_DETACH
(Above is copied out of perl/Tk code - I can't remember if the reserved
thing is truly reserved or if I just don't use it.)
I don't think threads get to see new DLLs loaded by their parent after
they were created unless they open them themselves - i.e. I don't
think the "struct" pointed to by fs:0 is same in all threads
but is rather _the_ per-thread info for the kernel which has some
well known offsets (and is presumably read-only to user-space).