This is the mail archive of the
mailing list for the glibc project.
Re: [PATCHv3] powerpc: ABI change - add HWCAP/HWCAP2/platform info to TCB
- From: Peter Bergner <bergner at vnet dot ibm dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: Carlos Eduardo Seo <cseo at linux dot vnet dot ibm dot com>, GNU C Library <libc-alpha at sourceware dot org>, Tulio Machado <tuliom at linux dot vnet dot ibm dot com>, "Steven J. Munroe" <sjmunroe at us dot ibm dot com>, "Carlos O'Donell" <carlos at redhat dot com>
- Date: Wed, 20 Jan 2016 14:56:29 -0600
- Subject: Re: [PATCHv3] powerpc: ABI change - add HWCAP/HWCAP2/platform info to TCB
- Authentication-results: sourceware.org; auth=none
- References: <4BE991CB-F601-4D63-A416-5991FE870FC4 at linux dot vnet dot ibm dot com> <alpine dot DEB dot 2 dot 10 dot 1509232114070 dot 10585 at digraph dot polyomino dot org dot uk> <B650304C-6207-46AC-B6A8-FA29959B305D at linux dot vnet dot ibm dot com> <alpine dot DEB dot 2 dot 10 dot 1509232141250 dot 10585 at digraph dot polyomino dot org dot uk> <1443046986 dot 23503 dot 68 dot camel at otta>
On Wed, 2015-09-23 at 17:23 -0500, Peter Bergner wrote:
> On Wed, 2015-09-23 at 21:43 +0000, Joseph Myers wrote:
> > On Wed, 23 Sep 2015, Carlos Eduardo Seo wrote:
> > > OâDonell suggested we used a versioned symbol to track this change, so
> > > it doesnât break applications when running against an old glibc:
> > But I don't see how the symbol, in the form you've added it, achieves
> > that. How do you ensure that applications using the new feature have an
> > undefined reference to this symbol? And in any case a symbol that is not
> > part of the public API, but is exported from shared libraries, needs to be
> > in the implementation namespace (__*).
> The idea is that applications will use the builtins supplied by GCC
> (and other compilers) and will not access this info directly.
> In GCC, my plan is to first add a configure test looking for the
> symbol and if it doesn't exist, then I'll make the builtins return
> false for all queries. If it does exist during configure, I'll emit
> code to load/test the TCB entries, but I'll also emit a data reference
> to the symbol which will cause a linker/loader error in the event the
> user attempts to link/run against an old glibc.
FYI, the GCC patch adding support for the POWER versions of
__builtin_cpu_is() and __builtin_cpu_supports() that use the TCB
just landed upstream in time for GCC 6. It includes the emitting
of the special versioned symbol as well as the GLIBC version check
in configure that Joseph wanted. Thanks everyone for your help!