This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Rd: [RFC] dl-procinfo and HWCAP_IMPORTANT support for powerpc
- From: Steve Munroe <sjmunroe at us dot ibm dot com>
- To: Brian Grayson <Brian dot Grayson at freescale dot com>
- Cc: Benjamin Herrenschmidt <benh at kernel dot crashing dot org>, libc-alpha at sources dot redhat dot com, Paul Mackerras <paulus at samba dot org>, Tom Gall <tom_gall at vnet dot ibm dot com>
- Date: Thu, 5 Jan 2006 13:33:33 -0600
- Subject: Re: Rd: [RFC] dl-procinfo and HWCAP_IMPORTANT support for powerpc
Brian Grayson <Brian.Grayson@freescale.com> wrote on 12/28/2005 03:34:17
PM:
> On Tue, Dec 27, 2005 at 11:39:40PM -0700, Benjamin Herrenschmidt wrote:
> > On Wed, 2005-12-28 at 00:11 -0600, Steve Munroe wrote:
> > > I don't have this kind info for the various flavours of PPC32
processor. I
> > > happily defer to those who have this knowledge to decide.
> >
> > We should discuss that with the freescale folks.
> ...
> A few years ago, the e500 ABI specified mechanisms for both
> toolchains and code to obtain information about what APUs are
> expected:
>
> - the .PPC.EMB.apuinfo section in an object file or
> executable specifies what version of which APUs is required
> by the object.
>
> - the __get_apu_revision() function provides a mechanism for
> userland to identify what APUs are available on the current
> silicon, and/or emulatable by the current OS.
>
> Note that this was not meant to be an e500-only feature, but
> rather something that could be used on many cores going forward.
>
> I believe apuinfo section support is in most embedded PPC
> toolchains nowadays (it's in binutils, for example), but I am
> not sure if all OSs support __get_apu_revision() yet. We did
> not specify an AUX_VECTOR type to specify APUinfo, but one
> could be added.
>
Note that glibc does not support the BOOKe ABI. Also __get_apu_revision()
is processor specific so not likely to be included in mainline glibc.
Embedded toolchains may be handling this a local mode or a separate
utilities library.
>
> It sounds like AT_HWCAP and apuinfo are two different
> solutions to the same problem, with different strengths etc.
> The APUinfo section provides finer-grain control (which
> revision of which APU, with support for up to 2^16 APUs each
> with up to 2^16 revisions), whereas HWCAP, with its limited
> bits, can only support the coarse yes/no control.
>
It sounds like to the PowerPC PVR. And I agree that it is different from
AT_HWCAP. The AT_PLATFORM would be derived from the PVR but again at lower
detail (a single string matching one of the -mcpu=<cpu_type> values.
Our kernel emulates the mfspr rx,PVR instruction for user state so
applications can get the PVR directly (at least with newer kernels).
Alternatively we could ask for a new Aux Vector entry (i.e) AT_PROCVER
that contains the PVR/APUinfo. I am not sure what the process is to add
new AT_* type beyond talking to the kernel folks. Eventual it should be
documented in the ELF ABI.
Steven J. Munroe
Linux on Power Toolchain Architect
IBM Corporation, Linux Technology Center