RE: aarch64 lacks HP_TIMING support in glibc

[Rafael Eduardo Ruviaro Christ <rafaeleduardoruviaro.christ@asml.com>]

Dear Wilco,

Thank you for your message. Currently, we're using glibc 2.28. As soon as I am able to update to the latest glibc I will repeat the tests in our platform to evaluate the clock_getres() behavior.

Kind regards,
Rafael

-----Original Message-----
From: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
Sent: Wednesday, June 23, 2021 1:43 PM
To: 'GNU C Library' <libc-alpha@sourceware.org>; Rafael Eduardo Ruviaro Christ <rafaeleduardoruviaro.christ@asml.com>
Subject: aarch64 lacks HP_TIMING support in glibc

CAUTION: This message is from an external sender

Hi Rafael,

> I noticed that aarch64 lacks HP_TIMING support in glibc. Although this architecture has generic timers, glibc is still using the generic hp-timing.h for aarch64.
> I see HP_TIMING support for other architectures. I'd like to know why there is no HP_TIMING support for aarch64?
> Also, if there's planning to support it for aarch64?

I added HP_TIMING support for all targets a while back - this uses fast timers via the vDSO mechanism. Some targets also have a header with an inline counter.

However it's not an external header and it is hardly used inside GLIBC, so it's not clear whether it's worth the effort to ensure that cntvct_el0 is never trapped on AArch64 or just declare the systems that do trap it obsolete.

Cheers,
Wilco
-- The information contained in this communication and any attachments is confidential and may be privileged, and is for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. Unless explicitly stated otherwise in the body of this communication or the attachment thereto (if any), the information is provided on an AS-IS basis without any express or implied warranties or liabilities. To the extent you are relying on this information, you are doing so at your own risk. If you are not the intended recipient, please notify the sender immediately by replying to this message and destroy all copies of this message and any attachments. Neither the sender nor the company/group of companies he or she represents shall be liable for the proper and complete transmission of the information contained in this communication, or for any delay in its receipt.