Re: [Tinycc-devel] TLS/__thread support

[Simon 'corecode' Schubert]

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   / \