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: Steve Munroe <sjmunroe at us dot ibm dot com>
- To: Benjamin Herrenschmidt <benh at kernel dot crashing dot org>
- Cc: libc-alpha at sources dot redhat dot com, Tom Gall <tom_gall at vnet dot ibm dot com>
- Date: Mon, 14 Nov 2005 10:05:54 -0600
- Subject: Re: [PATCH] hp-timing for ppc32/64
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 11/13/2005
10:33:03 PM:
>
> > 403 is already in the case of the kernel and glibc a bit
> > "iffy" given the state of support of powerpc cpus without floating
> > point hardware.
>
> How so ? We have perfect support for a lot of processors without FPU,
> like 4xx, 8xx, etc... and we have an FPU emulator in the kernel that
> allows an existing distro to run fine on these.
>
> > Additionally consider how many embedded boards with
> > 4xx chips got tossed since no one was maintaining them in the kernel
> > as a result of the recent ppc/ppc64 kernel merge?
>
> And ? How does that relate to our problem ?
>
> > I don't mind keeping 403 or 601 going for that matter. It's just a bit
> > of a challenged when you don't have the hardware or don't know anyone
that
> > does. (O ok, I fess up I have a series 1 tivo upstairs ...)
>
> Well, it's not like I was asking for something difficult: basically
> detect that bit being passed by the kernel and just don't do hp_timing
> when set. Just error out or use gettimeofday fallbacks or whatever. Easy
> to test by building a kernel that forces the flag anyway. And I do have
> a 601 machine just next to me :)
>
Trust me if it was easy I would have done it!
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!
Steven J. Munroe
Linux on Power Toolchain Architect
IBM Corporation, Linux Technology Center