This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] hp-timing for ppc32/64
- From: Benjamin Herrenschmidt <benh at kernel dot crashing dot org>
- To: Steve Munroe <sjmunroe at us dot ibm dot com>
- Cc: libc-alpha at sources dot redhat dot com, Tom Gall <tom_gall at vnet dot ibm dot com>
- Date: Tue, 15 Nov 2005 07:44:22 +1100
- Subject: Re: [PATCH] hp-timing for ppc32/64
- References: <OF58040575.94712F80-ON862570B9.00559A6B-862570B9.00586FF4@us.ibm.com>
On Mon, 2005-11-14 at 10:05 -0600, Steve Munroe wrote:
> dl_hwcap can't be accessed with a simple extern. In the dynamic case it is
> in the middle of a struct which for early loader initialization (i.e.
> before the loader has relocated itself!) is passed as a parameter. To
> handle the complexities of this environment we have to use the GLRO macro
> to access dl_hwcap. But I can't get the GLRO macro defined because
> ldsodefs.h includes several other headers which include hp-timing.h to get
> hp_timing_t defined. Of course these includes occur before GLRO is
> defined. So any compile that includes hp-timing.h or ldsodefs.h will fail.
> Many files are involved in a critical component and I just don't see the
> justification for ripping them up.
>
> The alternative it to leave hp-timing disabled for powerpc32 in the cvs
> trunk then use --with-cpu=power4+ to reenable it for the powerpc64
> machines (for 32-bit mode).
>
> Seems kind of selfish to me just so you can run your 60MHz 601 and avoid a
> little extra work :) I'll gladly provide the implementation for
> ports/sysdeps/powerpc/powerpc32/601/hp-timing.h if you will test it!
>
How do they implement hp timing on, let's say, x86 where they have all
sort of different time sources depending on the processor they are
running on ? They don't have access to dl_hwcap ?
Ben.