Re: libm compilation failing in -current

[Ignatios Souvatzis <is%netbsd.org@localhost>]

On Mon, Jan 04, 2010 at 07:10:48PM +0100, Frank Wille wrote:
> John Klos wrote:
> 
> >> Do you have any local diffs? Did you try a clean build?
> >
> > I just tried a completely fresh tree on an amd64 system and got the
> > same issue. I'm about to try on a macppc machine.
> 
> While I was trying to reproduce your 68060 userland build problem I ran into
> exactly this DT_TEXTREL warning. How did you solve it?
> 
> I analyzed some object files and found out that there are indeed 36 objects
> in libm_pic.a which have a .rela.text section. For example in s_atan.so the
> relocation looks like this:
> 
> 00000000 <atan>:
>    0:   60ff 0000 0000  bral 2 <atan+0x2>
>                         2: R_68K_PC32   __fplsp060_0038
> 
> All are coming from src/lib/libm/arch/m68060 and calling functions from
> Motorola's 68060 floating point library (which is the reason it didn't
> happen to anybody else before ;).

Well, while it might be interesting to have this in a compilable
state, I want to mention that after I did all the work to integrate this
stuff, at least optionally, all benchmarks I ran showed that the
kernel-trapping FPSP (with the normal m68k FPU instruction or whatever
it uses libm) was faster, at least on a otherwise loaded system.

The reason is probably that kernel-FPSP resides at a fixed physical
address (once the kernel is booted), so needs less cache reloading to
use.

I think I posted the benchmark results back then?

        -is