[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] Feature request: _Thread_local (and a possible bug)

From: Jared Maddox
Subject: Re: [Tinycc-devel] Feature request: _Thread_local (and a possible bug)
Date: Tue, 10 Dec 2013 00:57:41 -0600

> Date: Sun, 03 Nov 2013 23:34:50 +0800
> From: Thomas Preud'homme <address@hidden>
> To: address@hidden
> Cc: Robert Clausecker <address@hidden>
> Subject: Re: [Tinycc-devel] Feature request: _Thread_local (and a
>       possible        bug)
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset="us-ascii"
> Le jeudi 31 octobre 2013 16:17:00 Thomas Preud'homme a écrit :
>> Le mercredi 30 octobre 2013 19:40:10 Robert Clausecker a écrit :
>> > I see nothing in the patch you made that indicates any special access
>> > conventions to thread-local variables (such as %fs-relative
>> > instructions). It might very well be possible that I missed that, but I
>> > can't test because tcc does not compile the code at all on my machine.
>> Right, it just handles the syntax and the ELF part. I'll improve the
>> patch.
> Well, I was way too optimist as to the complexity of TLS. After reading the
> document from Ulrich Drepper on TLS and a few search on google I realized
> that
> at least the following are missing :
> - segment register not select in load and store
> - no relocation added for computing offset of per-thread symbol
> - no support for TLS-specific relocations (link-time and run-time)
> - no program header added as per Drepper document about TLS
> I also need to think about what part of the dynamic machinery are needed for
> tcc -run and what part will be taken care of by ld.so. That answer might be
> obvious but it's getting late for me and I haven't given it much thought.
> Since it's going to take some time to implement, I'll give the priority to
> other long work I had put aside such as ARM calling convention refactoring
> (+
> add comments) and returning of struct in registers. In other words, TLS is
> not
> going to happen soon.

Over the last few days I've run across some info that's relevant to
this for Windows, so I figured I should post links here for archival

First, running arbitrary code on a thread at arbitrary points in that
thread's execution:
That link talks about simulating an OS on Windows, but it's the only
way that I've ever heard of to do that particular job. The direct
equivalent for *nix would be signals, some of which take control of a
currently executing thread, much like this does. I once looked at
using signals on Windows for a toy user-space OS, but normally they
get thrown off into their own thread instead of using the current one,
so that didn't work.

This is relevant for when you directly load into memory instead of
writing to a dynamic library and THEN loading via system call.

Second, allocating & accessing thread-local memory on Windows:

You need to scroll a fair amount to get to the relevant bit. I don't
think that information's particularly scarce, but that page is what
made me think of this again, so I figured that I might as well post it

reply via email to

[Prev in Thread] Current Thread [Next in Thread]