[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: TLS support patch
On Thu, Apr 07, 2011 at 05:23:39AM -0700, Matt Thomas wrote:
> 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.
The question was more about kernel page acess vs the register.
> 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.
Are there ARMs with SMP that don't support the register version?
acorn26 is UP only, isn't it? So it doesn't raelly require a per-cpu page,
just a fixed kernel page mapped into userland. The full pmap changes are
only needed if the first question has a positive answer.
Main Index |
Thread Index |