Simon 'corecode' Schubert wrote:
No, it needs a relocation entry of type R_386_TLS_LE (for the object
file) or R_386_TLS_TPOFF (for a shared object). Of course, before, the
variable access has to be constructed to use %gs relative addresses. So
the code generation path would have to be changed for that as well.
Okay, this is the moment I start asking stupid questions:
I've kind of tracked down the place to add the functionality between gv() and
load() and vstore()/store(). I guess it would be cleaner to put it into
load()/store(), however, my problem is that I need another register to actually
calculate the offset.
To illustrate, consider this code fragment produced by gcc:
__thread int i;
void f(void){ i = 1; }
produces:
e: 65 a1 00 00 00 00 mov %gs:0x0,%eax
14: c7 80 00 00 00 00 01 movl $0x1,0x0(%eax)
what happens here is that %gs:0x0 contains a pointer to the thread local
storage block in which the tls variables are allocated (the 0x0(%eax) is
relocated on link).
So, for every load and store, I'd first need a register to read the pointer
from %gs:0x0, and then I'd need to generate a register-relative load/store.
But I think I am not allowed to allocate a register within load() or store(),
so what would you people suggest to do?
Of course I could generate some push %esi; mov %gs:0x0,%esi; mov ...,0x0(%esi);
pop %esi code sequence, but I'm not sure if this is to much of a hack.
cheers
simon
--
Serve - BSD +++ RENT this banner advert +++ ASCII Ribbon /"\
Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ /
Party Enjoy Relax | http://dragonflybsd.org Against HTML \
Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \
_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
