[PATCH 6/6] aarch64: Add hp-timing.h
Richard Henderson
rth@twiddle.net
Thu Sep 10 00:33:00 GMT 2015
On 09/09/2015 04:14 AM, Catalin Marinas wrote:
> What are the glibc expectations here for HP_TIMING? Is it fine if it
> always returns 0? Does its frequency need to be known? If yes, how do we
> expose such frequency to user space?
Yes it's fine if it returns 0. You just won't get useful timing info when
using LD_DEBUG=statistics.
No, we don't require a known frequency. Even on x86 we simply print "cycles"
rather than a scaled time.
I think the only real requirement is not crashing due to sigill while
collecting the statistics. ;-)
> IIUC here it's a simple HP_TIMING_NOW macro which translates to an mrs.
I did that simply because it worked for me. You'll notice the significant
push-back that patch elicited. ;-)
> Do you plan to add further checks for HWCAP here?
If required. It ought to be easy.
> Is exposing a reader function via VDSO be feasible here? Or it's too
> early for the dynamic loader?
Good question... it's on the edge, right after self-relocation of ld.so, but
before proper relocation of libc and re-relocation of ld.so (e.g. to use libc
symbols like malloc instead of the bootstrapping stubs).
Finding the VDSO is certainly easy, since its pointer is in auxv, and we will
have stored that. But how much effort it is to look up a symbol by name for
that at that point in the bootstrap, I don't know.
Would the kernel be likely to provide an implementation that wasn't simply the
mrs insn?
If not, I don't know that's any better than the HWCAP bit. Either way we need
a test-and-branch. Whether that's checking for a null pointer because the
kernel didn't provide the vdso entry point, or checking hwcap for the bit, it's
just about the same.
r~
More information about the Libc-alpha
mailing list