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] 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


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