Re: [Tinycc-devel] TLS/__thread support

[Rob Landley]

On Sunday 26 August 2007 6:31:36 am Simon 'corecode' Schubert wrote:
> 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'll answer what I can, but I've never used thread local storage on Linux.  (I 
mostly got threading out of my system back under OS/2 and Java...)

> 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?

It seems to me that tcc does an awful lot of register spilling to the stack.  
It sucks from a performance perspective, and makes the compiler 
implementation really simple.  (Its' register allocation policy is, more or 
less, "don't".)

> 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.

It's what the rest of the code does.

Another interesting point is that there's an arm target (which probably needs 
to be cleaned up and genericized so we can add x86-64 and powerpc and mips 
and so on as output formats too).  What would be involved in adding this 
support to the arm target as well?

Keep in mind that x86 is going to become an obsolete format in 2008, which is 
about when the installed base of x86-64 hits the 50% mark.  Both Intel and 
AMD stopped making non-embedded 32 bit processors late last year, you know.  
Existing inventories in the channel are all she wrote...

> cheers
>   simon

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.