This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] powerpc: New feature - HWCAP/HWCAP2 bits in the TCB

On Sun, 2015-07-05 at 22:13 -0400, Rich Felker wrote:
> On Sun, Jul 05, 2015 at 08:16:44PM -0500, Steven Munroe wrote:
> > > I've suggested to Carlos that this is a problem with the use of the
> > > TCB. If one uses the TCB, one should add a dummy symbol that is versioned
> > > and tracks when you added the feature, and thus you can depend upon it,
> > > but not call it, and that way you get the right versioning. The same
> > > problem happened with stack canaries and it's still painfully annoying
> > > at the distribution level.
> > 
> > This is completely unnecessary. The load associated with
> > __builtin_cpu_supports() will work with any GLIBC what support TLS and
> > the worst that will happen is it will load zeros.
> That's bad enough -- there are applications of hwcap where you NEED
> the correct value, not some (possibly empty) subset of the bits. For
> example if you need to know which registers to save/restore in an aync
> context-switching setup (rolling your own makecontext/swapcontext) or
> if you're implementing a function which has a special calling
> convention with a contract not to clobber any but a small fixed set of
> registers, but it might callback to arbitrary code in a rare case (ala
> __tls_get_addr or tls descriptor functions).
No! any application that uses HWCAP and or __builtin_cpu_supports, has
to program for when the feature is not available. The feature bit is
either true or false.

The dword we are talking about is already allocated and has been since
the initial implementation of TLS. For the PowerPC ABIs we allocated a
full 4K for the TCB and use negative displacement calculations that work
well with our ISA. 

None of the existing TCB field offsets change. So this add is completely
upward compatible with all current GLIBC version.

None on the issues you suggest exist in the this proposal

> However I don't even see how you can be confident that you'll read
> zeros. Is the TCB field before this new field you're adding
> always-zero?
The TCB is allocated as part of the thread stack which is mmap, which
kernel initializes to all zero.

> Rich

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]