Re: Better backtrace (wasRe: pqReadData() -- backend closed the ch

On Wed, 1 Aug 2001 16:07:59 +0000 (UTC), Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Well, the bottom line seems to be that there's something broken about
> the floating-point support on that box. Look in

>> uname -a
> FreeBSD jc12.easthighschool.net 4.3-RELEASE FreeBSD 4.3-RELEASE #0: Sat Apr 21 10:54:49 GMT 2001 jkh(at)narf(dot)osd(dot)bsdi(dot)com:/usr/src/sys/compile/GENERIC i386
>> gcc -v
> Using builtin specs.
> gcc version 2.95.3 [FreeBSD] 20010315 (release)

>
> I speculate that your box is so old that it has no hardware floating
> point at all, and that what we are seeing here is a fault in FreeBSD's
> software emulation of the 'fild' (short-to-double) instruction. Or
> maybe it's an assembly-time problem. A google search turned up
>
> http://gatekeeper.dec.com/pub/BSD/FreeBSD/FreeBSD-current/src/contrib/binutils/include/opcode/ChangeLog
>
> which suggests that older versions of the GNU toolchain may mis-assemble
> 'fild' instructions.
>
> It'd be worth asking around in BSD-specific mailing lists to see if this
> is a known problem; I didn't find anything else in my web search, but I
> wasn't trying very hard. I think Postgres is off the hook, in any case.
>
> regards, tom lane

I recompiled the kernel replacing

options MATH_EMULATE
with
options GPL_MATH_EMULATE

and I am now able to access the database normally.

As an experiment, I had another 486SX (no hardware fpu) which showed
the exact same problem when I transplanted the hard drive. So it
looks like this may be a problem which will show up on the older
486 machines, but can be worked around by recompiling the kernel
with the alternate math emulation code.

I sent a report of your findings to one of the freebsd mailing lists.

Thanks again, Tom.