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
above).
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
possible.
-Michael
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
