[fpc-devel] threadvar implementation

Michael Schnell mschnell at lumino.de
Tue Aug 3 10:44:51 CEST 2010

  On 08/03/2010 01:37 AM, Hans-Peter Diettrich wrote:
> Michael Schnell schrieb:
>>> You only have to determine the flat address, before storing it in 
>>> the pointer variable - @MyThreadvar?
>> How do you think this is possible ? How to you think it's possible in 
>> FPC to define a pointer that does not use DS to access the memory 
>> location ?
> No need to do so. Every accessible byte must reside in the 32/64 bit 
> address space, so it is addressable by DS and an offset.
Sorry but wrong (IMHO) with pointers to threadvars in X86/32 Linux (see 

While indeed (supposedly) any threadvar is allocated withing the address 
space of the process (addressable by DS:), the user software has no 
chance to calculate this offset, as (AFAIK) it can't read the selector 
table entries that are pointed to by the (different) values in the DS 
and GS registers, which would be necessary to "rebase" the threadvar 
address that is relative to the entry table given by the GS content and 
a target address relative to the table entry given by the DS content.

Regarding the hardware and without rewriting or switching the selector 
table, a user land program could access 64K different (potentially 
non-overlapping) address spaces (each 4 GB size) using a selector 
register such as ES.

Without writing to a selector register and explicitly using a selector 
register in any ASM instruction, a user land program can theoretically 
use three different (potentially non-overlapping) address spaces: CS for 
instruction reads, SS for data access relative to the stack pointer and 
DS for all other data access. Of course the OS sees that DS and SS 
content is identical, so that pointers to stack based variables are 


More information about the fpc-devel mailing list