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 Mon, Jul 06, 2015 at 08:26:46AM -0500, Steven Munroe wrote:
> 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.

I don't think you understood what I was saying. False negatives for
__builtin_cpu_supports are not safe because they may wrongly indicate
absence of a register you need to save on behalf of unknown
third-party code. I already gave two examples of situations where this
can arise.

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

I don't see this in glibc. struct pthread seems to be immediately
below tcbhead_t, and the latter is not 4k. I'm looking at:;a=blob;f=sysdeps/powerpc/nptl/tls.h;h=1f3d97a99593afbd3c56318eaa6d7a2d03a59005;hb=HEAD


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