This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [ARM] bits/hwcap.h update
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Phil Blundell <pb at pbcl dot net>, GNU C Library <libc-alpha at sourceware dot org>
- Cc: <nd at arm dot com>, Joseph Myers <joseph at codesourcery dot com>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>
- Date: Tue, 13 Dec 2016 11:51:44 +0000
- Subject: Re: [ARM] bits/hwcap.h update
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Szabolcs dot Nagy at arm dot com;
- Nodisclaimer: True
- References: <584EE1D4.3080201@arm.com> <1481573345.17921.93.camel@pbcl.net> <584FC1BA.2020600@arm.com> <1481628506.10018.11.camel@pbcl.net>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On 13/12/16 11:28, Phil Blundell wrote:
> On Tue, 2016-12-13 at 09:39 +0000, Szabolcs Nagy wrote:
>>
>> they are always linux specific because linux can
>> define new ones (if there is space) so the question
>> is if there is a reason now to invent new names
>> instead of exposing linux uapi names.
>
> Using the kernel names would make it impossible (or at least awkward)
> to access both the arm and arm64 definitions simultaneously, since the
> kernel uses the same names for both but the numeric values are
> different. In analogous cases having to do with ELF for example, the
> macro names are all namespaced by architecture so they don't collide.
> But I can't immediately think of any realistic situation in which one
> would want to do that for hwcaps, so it probably doesn't matter very
> much.
>
> Conversely, we clearly can't just drop the existing glibc names and I
> am not all that thrilled about glibc having to maintain two names for
> all these macros in perpetuity. And it's not entirely obvious to me
> that there is all that much real benefit from having the names be
> aligned, so I think I would be inclined to just leave it alone.
>
> I suppose one could argue that the glibc names are "better" and if
> alignment is desirable then the kernel ought to change (and it might
> even be possible to do that without maintaining backwards
> compatibility, given that I suspect most applications are in practice
> using the definitions from glibc rather than the ones from the
> kernel). But I imagine any such suggestion would meet with resistance
> from the kernel folks.
>
other platforms (e.g. bionic) don't have the glibc
names (which are not documented anyway) and we need
to sync new hwcap names from the kernel (HWCAP2_*)
and it does not seem right to keep inventing new
names for those.
sh4 should also expose the CPU_HAS_* definitions,
powerpc already exposes PPC_FEATURE* in bits/hwcap.h.
(when i added arm HWCAP bits to musl i used the
linux names, beacuse i didn't know glibc invented
something else, i assume other implementors do the
same: go makes a subset of HWCAPs available using
the linux names)