This is the mail archive of the libc-alpha@sourceware.org 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 rsa/hwcap2_v4] Implement AT_HWCAP2 version 4


> I have one primary concern with my patch set in general.  I'm not
> entirely sure how the LD_HWCAP_MASK and HWCAP_IMPORTANT masks are
> affected by AT_HWCAP2.
> 
> Looking at _dl_important_hwcaps:
> 
>       GLRO(dl_hwcap) |= (uint64_t) mask << _DL_FIRST_EXTRA;
> 
> This appears to use the high 32-bits of the hwcap for the pseudo-hwcap
> bits (like TLS or anything passed in LD_HWCAP_MASK).

TLS does not really have a bit any more, though ldconfig still treats the
highest bit specially because it used to (probably that should be fixed).

High bits are used for _DL_HWCAP_PLATFORM on some machines (i386, powerpc,
s390), i.e. a bit corresponding to each expected AT_PLATFORM string, and
for dsocaps (which is what the line you cited is doing).  That's all been
kosher in the past because we assumed that AT_HWCAP only ever had the low
bits set.

LD_HWCAP_MASK is something else; perhaps you're confused about what it does.

> On Power I've allocated all 32-bits of the high-word (since the kernel
> folks implemented the PPC_FEATURE2 bits starting on the high-end).

That makes an immediate problem what would otherwise have been a lurking
problem.  So perhaps that's good, but it means that we have to get the mess
cleaned up now rather than later.  I think you really have to figure out
and clean up the whole situation before we can do AT_HWCAP2 support.
Sorry I did not think of this earlier.


Thanks,
Roland


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