Re: TLS support patch

[Matt Thomas <matt%3am-software.com@localhost>]

On Apr 7, 2011, at 5:04 AM, Joerg Sonnenberger wrote:

> On Thu, Apr 07, 2011 at 04:50:59AM -0700, Matt Thomas wrote:
>> Assuming we just don't have __aeabi_read_tp just to a
>>      mrc p15, 0, r0, c13, c0, 3
>> and take the emulation hit, what mechanism should be used?
> 
> __aeabi_read_tp is part of the ABI and the calls get hard-coded. There
> is another ARM TLS spec, which seems to depend on a fixed memory
> location, but I am not sure if that actually got implemented.

Haven't come across that in my investigations.

> The easiest approach would be to require the kernel page to exist
> and use that by default. If the above is faster than using the kernel
> page, the __aeabi_read_tp could be provided as DSO loaded on demand.
> Having the kernel page as required part of the kernel ABI would allow
> implementing the/an alternative ARM ABI using a plain TLS_TP relocation
> instead of branching.

The kernel page method is much faster than the emulation (4 instructions .vs. 
hundreds) but it's much harder to implement.  Hopefully no arms need to use 
0xffff0000 for device access.  This actually requires two pages: one for the L1 
PTP for 0xfff00000 and one for the actual page.  Since TLS will only occupy the 
upper 32 bytes, we could just use this as a global common page.  I have no idea 
how to deal with the 26bit address space for acorn26.